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

Stephen Kent <> Mon, 23 March 2020 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBCC33A00AD for <>; Mon, 23 Mar 2020 06:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.563
X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ryv1SdPh5G2M for <>; Mon, 23 Mar 2020 06:33:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 815D73A0028 for <>; Mon, 23 Mar 2020 06:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a2048; t=1584970404; bh=BzoDYPxX86QWpBX8iBCnvDG/sgIjnByOMaPTpwRrf3E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=hlkmIhcdET1k3LdDCOibFGUnkMlc4lcjX+WZgt9CR5mvcuRV4Ey1r3U8p4E5fTrO1J80N6oaVxHOIMKmZYhy/daplASlX2uvDfH2fPFDZENVLJAfhfZMQjxFVUdBiEmSdvjsbsxJLOffZHZHOdEeF81je/7rHLf8+zsMBTtEBV5ZqzSWD3EWsB+54dSBnWzK4Gfad86eJ0eeve6CuOGkYk5rgkDmlmKbWEF/lQ8LAbX+5AbSV3AIGnV6UxKkqKAjwFyDQEBWQHPROIxyLQ2M4nHQIfNxF4orQFDPabTufCef+YvSf9dzbTIq2P5MjtKyd5fzu6JbYLOup+PUwGvWDQ==
X-YMail-OSG: 97hby9MVM1k75S6U7BULOOxTRMA5TPPgSDRbAAlVCB1hA.4DgOPrNqpOFcslYLs wQUMn38A6o8sQ2sbkUtGg7Kd9U8ZlGirbcgZTCTXCSkwuyZyJ1B1UPmhhzUtYniQx93bVvOI.WFT e_1nDtpOLU7FuZ48hgritpHY9G7xeU182nevcmrGGzLtN6yTf.J9uuf0PTw96SKdjRsnNKUnvex_ KL3X5nouBBhP0OGUN4.ZP6P8.swLxGlZ9zL78BiN6pZufLKyTIPPNCRhnKya.qb0wejosMdZarFg QCgziWIKrwQENlaKlJLqTMEjECXewOc0DupsYS_IjZnTplw70PIXdgA3kkKjgBe53Hq7Zwp2978A fxQorwfcv9BxIZ4Pz5Ow8VDX7WwaX9qibMWjpJxo_F0ySixmMeqRdCLJ8cu5FrDyioHVo2VNiavS SS4gJc8UHTYqh7QOLONPwNMooM_NqR26D4pbZpGwQI7wVtBeBXOglJlr3DopvhF9rW1UDR4Q0ijY U6A3q441kXWH9FDkWpQpz9iYNOgJDtyNj8IGTm0KJ7PTR9iBsVwaTRF8d_v802GENk6jsxDfU0_M hYhUQLHxJPo.x4sWf0.PARnzC_G_1hzfRDmDMgX.SX8_uq_jOL74oMzFnUXJdWGUBqqYGLRnUilN fJoBLavI9qMbCfFdPPime7XyaQ3TBjN4XoyzwuVUQblSbPdGYo8WQ113UDTbjw6isqnWBUc7KEkF 5HIdQbmrL0j3WBoMVdv5HOHOnJBPLtojsLGHr08AoWMpmV.LrmmGEDy7r21WON8NJ9FLyo71cmDE yl35L6XBTxT2CdY7yXPg3Y02JwaQq71i6sZiAxNIhi9pVtCZccyo31AMN.Xxnu3kXd5pqYoTITBm 1yy5sDRcxSMs8ZsQinANqHBM4jwTYtUVOX53cyCMFMEvzE.jshG9KayJKYbseO_zcfDNhrJF.8hX hwYbEGZG8zLMoLJpAQUNkP0Lr8hWf_RLi2prWqhzVpbTy46Xjo_8mlVGExWaRxsy03Z2.DD.Cd4r TBTlF5xH0m3U2uhZmHMmwkYkx8xtBfOkkHo1MNckRQ7dLrFtG3sd6OC6sU3KsTSJuBKw.9aNaCFH 056wlKS_SZBVj34fZl9ub8PLlvLFjPvpetibVpjwF4YURXP0gWAQykQ.EBpNqKnDINvfRUmSopSK 8YJj6_I.7KHKWj7fsGHxHdY8Wo.1UTYhiHCUw0X0ILBphJI..g_WiWEh0iN6zq0Zieq2cpshPD_2 M2qr_oEVQ4mhP4NSextNYWhRVKGc80cw_sVmYiWL8hDOrNpLBsS.kCBGRisztO1gPKfPnlX0_NSH xTpdghRg03qbeGcC.dFo7sujdlHyKaqBwCrbgJeGcS4CucqDu9qj.7Kr_duP692oZj2wX7CqfqT3 gl4x11x8gViHb98UubulzBrVjjrII45tP5TAkJWNes3VYGyD1MNmZA6Q_g66jokFZ.hs-
Received: from by with HTTP; Mon, 23 Mar 2020 13:33:24 +0000
Received: by (Oath Hermes SMTP Server) with ESMTPA ID 48dcff255d0ccc7334654d01c4eb7cf5; Mon, 23 Mar 2020 13:33:20 +0000 (UTC)
To: Tim Bruijnzeels <>
Cc: SIDR Operations WG <>
References: <> <> <> <> <> <> <>
From: Stephen Kent <>
Message-ID: <>
Date: Mon, 23 Mar 2020 09:33:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241)
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: Mon, 23 Mar 2020 13:33:27 -0000

> 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. 
That's a very forward-looking perspective, one I had not considered.
> 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?

I agree that with strict Manifest processing, CRLs provide redundant 
info. But, by that argument, why bother checking to see if certs are 
expired, since that too is redundant in a strict Manifest processing 

> 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.

redundancy is often beneficial in security systems. it helps prevent a 
single error from having terrible consequences. But, this strategy works 
only if one is flexible when responding  to an inconsistency between 
redundant pieces of info.