Re: [Sidrops] what to do when the CRL is hosed?

Tim Bruijnzeels <> Thu, 27 February 2020 09:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9AA33A1651 for <>; Thu, 27 Feb 2020 01:27:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZUEt9Q97VAEb for <>; Thu, 27 Feb 2020 01:27:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EA0A3A164F for <>; Thu, 27 Feb 2020 01:27:09 -0800 (PST)
Received: from [IPv6:2001:981:4b52:1:dc65:bf07:8257:debe] (unknown [IPv6:2001:981:4b52:1:dc65:bf07:8257:debe]) by (Postfix) with ESMTPSA id 4830B2DDE2; Thu, 27 Feb 2020 10:27:07 +0100 (CET)
Authentication-Results:; dmarc=fail (p=none dis=none)
Authentication-Results:; spf=fail
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1582795627; bh=Z2/lNHjVoHsP/QkxB0ilV0xZDFRMekrWxP1Tcelk7ww=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=sKF6xTjdfPBWSvMFhyUu8M2zNeLXhet5Gq2GDLum3PRiB363HHOoLr7J+Sxw68rs2 xrPCoxVrU0DMYL7BMxxVj0fkGkmsIF1X+UZWJaJ2x+I/qZxl9uOYBqJX56I0MTd5oW LEZrhVtNlRt1VSepStN9yGd5qosD7DjTS2NCsTf0=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Thu, 27 Feb 2020 10:27:06 +0100
Cc: SIDR Operations WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Stephen Kent <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
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: Thu, 27 Feb 2020 09:27:12 -0000


> On 26 Feb 2020, at 18:03, Stephen Kent <> wrote:
> Tim,
> Thanks for your thoughtful analysis of the options. Her are some additional thoughts.
> In general, a stale CRL still represents the best info re revoked certs available to an RP, so ignoring it does not seem appropriate, to me.

In general I agree. Which is why I mentioned the example of objects one might find published outside of the context of the RPKI repository, and *not* listed on a manifest. Such objects have yet to be invented but theoretically one can think of signed structures under an existing RPKI CA cert (e.g. using their own embedded EE) - which is shared out-of-band between parties.

> In the RPKI we also have Manifests, so if a Manifest is current but the CRL it references is stale, then that strongly suggests that the CA has encountered a problem generating a new CRL, but it's still the best revocation status info available, so use it and consider contacting the CA (via the GB record) to point out this problem.
> A CRL is invalid if it's signature doesn't verify, or if it has a syntax error, even in the face of a valid sig. In this case I would ignore the CRL contents, contact the CA, and keep using the freshest CRL the RP has.
> Because these CRLs MUST contain sequence numbers, receipt of a valid CRL that appears to be current, but has an older (or the same) serial number relative to a previously validated CRL is suspicious. I would definitively contact the CA to see if it just forgot to increment this field properly. I probably would stick with the freshest CRL info I had for that CA until the matter is resolved.
> There are more cases one can analyze, but I think the basic approach is to stick with prior, validated CRLs and contact the CA that issued the questionable CRL, until the matter can be resolved.
> As for the considerable leeway accorded to RPs in the Manifest document, I concur that it allows inconsistent local behavior. If the WG can agree on more proscriptive language, that would be good. When we wrote 6486 we were unable to agree on such, as we tried to balance robustness vs. responses to possible active attacks on repositories or communications between an RP and a repository.

What I am suggesting is that we *could* update 6486 and make validation more restrictive regarding manifests:
- all objects on a manifest must be present and accounted for (I agree with Job regarding partial withhold attacks)
- all objects on a manifest need to be validated
- objects that are not on a manifest can be considered invalid

This is in-line with the specifications defined in RFC 6481 (A Profile for Resource Certificate Repository Structure), which essentially says that all current objects must be published, and that no invalid objects may be published.

Then, if the manifest is already a signed statement of everything that is current, at least regarding the currently defined object types, as defined in RFC 6481, then what is gained by checking that CA was also capable of generating a CRL - using the same authoritative key and publication method - that confirms that the objects that are current according to the manifest are indeed not revoked?

Requiring the CRLs just feels like unnecessary brittleness to me (again in the context of RFC 6486). It creates multiple loci for bugs in CA implementations, and complicated error conditions that need to be checked by RPs. This is what I meant with the perhaps poorly chosen word 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy may seem like a good idea in general, but in this case it really only allows for the possibility of two conflicting signed messages. Thus it seems that this does not increase security, but provides more ways for things to break.

Don't get me wrong.. we *are* generating the CRLs in unison with the MFTs. And for this to change one would have to make update to the manifest RFC and restrict the validation rules in a manner like I am suggesting above.

I am just asking that we consider that.

Kind regards,

> Steve
> _______________________________________________
> Sidrops mailing list