Re: [Sidrops] trying to limit RP processing variability

Stephen Kent <> Thu, 23 April 2020 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B0DB3A097B for <>; Thu, 23 Apr 2020 07:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.919
X-Spam-Status: No, score=-2.919 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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 VTmYMG9dkl27 for <>; Thu, 23 Apr 2020 07:46:10 -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 DD40D3A097E for <>; Thu, 23 Apr 2020 07:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a2048; t=1587653168; bh=Db/lXTraQhPg3PLIVxVhcntP6oIku9AXDpfytzwW46o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=HMwh6uPMO1ExeUOk3PiH8Ze4cPHY+gxq9uOTT7x0YRf42qeAuDDSldWLSqoV4n7wBLqnMv3kKKG7HhvukOyM+W4yWngqgDIXzeBut0EsjwD/VRl8hRqkOkzpNSxcFjULFT0eGmuY+IfwVF9+LvGSRqOnJJQF8el8n2z7rsz5bjU3y8eWHyTsMMMVO/pvC4zraIrgTMzlmFJnSoZ15jrK9pRbfEIwRlN9IQvCQnNOFnhA3NJBv4dNtYoJ/j9fR4Qnqv8R3S9r1po4noES0hA/XMfRZdkT63ZlTlGteXdaUiRioK5a06Y6G7RPOnWmw7/m4UG1iNS/bW5IgNBrl+XqhQ==
X-YMail-OSG: NXPZQbcVM1mgv86rqvz4J4YquGOkSIkIQ35AfmETSjBshXROmnwQRrJEFtewPK3 xxVxv0OHwixfGUoorlWifi_YKLMvl5BcES9Ig90DilujF137CeYIt7lflwd9.rotsv6ebaXNM3i9 AsQTQpF8uASmc40vNK4S.eFlPPdn0NWRuL1so8c1gpBnbdFSbdcaLr66tVMJTPK8.W0kTQTbGjkt GGd3D4.SCulD8rSI6znMmwyz1OTFC1jqhanLidVdnnNAxXdh._ysum6zhSJiaPlUu4zNqafAzKU1 mpWRcDRZ0lFc7gYXu6beEf__7X610VhCR6nMbFlOgTz2cqRcW9y2yu2nxR.ASAF_uCbcg15doiro vme3ZPHWvv89FQy8dnCMYxjtPqG9vno_PQVrdTC2zZ.hT8ZLEtVEhPz01psr32TwviuxQ.abQ_KJ y_F1Crbe6XuRp6GIAyyE1ppw8dtV.b1SZt14y7kYeTqs5Jm7LHakAIhFxQ1olJ7VR5cd7KVXGnpq BbcDc00lw6aYgZFHOwnkOP3nJejmn9u7sJO3riV5ILoOYPsm4mQ77v8CdN17lN1nldKY8P2k2NXL NxTNT6dt4riO.IMD3Xvr5LanKL1Y_LPGk4eD3pWz1pkQaPnEwCbIwtYBAzFH4Ub7UcZF8yoTidDd uhqyseBe.STYtGGvFy6DXrXFyg8FFNgvGT3TtpwvTlJYE_NBkQzUVlLCPjxSCfhF0p_VhNkzbGvy TFknKwvougEk_9u4gazVGO8gyUqb7DTGIxXrxNaliGzRAQHbCsDWBlemvEObxmEOxoVf9Z0P_FaT Poa2fgwjPfx4U1El7lcPLDo2A5q3eE__c7m2wVxSyE8BxjGgQZFz3flq9UenBqp3DkE7huOD93Ey hO13543x4_T2FSBz2OudlHt1w9ClrUJWCTNf97PgqWZ61PjgvthqXHKEhAS5.EV3fXDr3Sr9BaNJ eoMxsPKFbv4gjKIEcI5xYBdiKvunW8071PWvHA1UNVx7WOZcqVQYS1zxQoNFOpgdySyzrDiXwrzU dfwitrWvtSTsVbMhIuHF6TRPj5lddSuEDBZIZ_k11UMLsQo6AM2rDLewmjw0Ny8TGfAi7d2Va5iO q.dWhoXMezeQM6HEMJdl8X1qxV6zrH0Z4C2tqvhoCj6N0i0Wa1cNdF1PLIRFba8a4ed6uNjxwLg4 1ctFx6qAwahNkaqVA4WPzZXHGiFQfrXmsLNgriTpmaV55MuykSl3Q8QxldEFGe9CNdKKtMqEx4Hq 4atbt9g2L1N8vSSKSz2ESAV6mqJz2JOxakXbsSh0G3zK4LRj.BArt5s8to3jrIhaPqtrHvVPz8jo vLDMv4UxPAvMn7RPbevzMiXhqScvbYKRMrFgd1yS7elDyVT3mJLsmuwiZTvBz9KE.Zj4OvhdQXFD zLeR1lx_A4_BHhsHQFyU9FpNaYFJOPZo5IFRl6S4aMPU1GsuMWvrR2A8u6dYmgbVHM0NR
Received: from by with HTTP; Thu, 23 Apr 2020 14:46:08 +0000
Received: by (VZM Hermes SMTP Server) with ESMTPA ID 1c84b367f7a6c06df3001abc04052854; Thu, 23 Apr 2020 14:46:05 +0000 (UTC)
To: Martin Hoffmann <>
References: <> <> <> <> <> <> <>
From: Stephen Kent <>
Message-ID: <>
Date: Thu, 23 Apr 2020 10:46:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------825991FC31A40891EF72BD95"
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <>
Subject: Re: [Sidrops] trying to limit RP processing variability
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, 23 Apr 2020 14:46:12 -0000


sorry to be so tardy in replying.
> Stephen Kent wrote:
>> Martin,
>>> ...
>>> That wasn’t quite the case I was thinking of (although I think this
>>> is a case worth calling out specifically to avoid confusion), but
>>> rather a case where say, a ROA’s EE certificate contains a URI for
>>> the CRL Distribution Point that is referring to a CRL that is not
>>> listed in the issuing CA’s manifest.
>> This would be an error by the CA. RFC 6480 notes where the CRL is
>> supposed to live in the repository system.
> I know I am being pedantic (but then implementers are surprisingly
> creative), but I can’t find normative text in RFC 6480 either that says
> there must only be one CRL per CA.

In some cases there will be more than one CRL issued by a CA, e.g., 
during key rollover. But I don't think that's the real issue here. The 
text associated with Figure 2 in 6480 (page 13) says "... the SIA 
extension of certificate A points to _the_ repository publication point 
of CA A's subordinate products, which includes certificates B and C, as 
well as _the_ CRL issued by A. The CRL Distribution Points (CRLDP) 
extension in certificates B and C both point to _the_ CRL issued by A." 
That text, and Figure 2 itself argue that, under normal circumstances 
(vs. key rollover or alg transition), there is just one CRL associated 
with a CA and it lives at the same PP as the other subordinate products 
signed by the CA.

>>>>>       1.Manifest present, valid, current
>>>>> If there is a present, valid, and current manifest, the CRL can
>>>>> safely be ignored for all objects.
>>>> Tim has suggested that, but to do so would make the RPKI not
>>>> consistent with RFC 5280.
>>> I’m not sure. In section 6.1.3, RFC 5280 says
>>> |  (3)  At the current time, the certificate is not revoked.  This
>>> |       may be determined by obtaining the appropriate CRL
>>> |       (Section 6.3), by status information, or by out-of-band
>>> |       mechanisms.
>>> Determining certificate revocation via lack of presence on a
>>> manifest could be construed as an "out-of-band" mechanism.
>> This part of 5280 is designed to accommodate OCSP as a revocation
>> status distribution mechanism, something that was not part of X.509.
> If it intended to only allow OCSP, it should have said so. The way it
> is formulated now, it opens up the option to devise any appropriate
> mechanism.
I agree that the wording is very broad; the principle author of 5280 
liked it that way. But, as the PKIX chair my view is that the text was 
intended primarily to accommodate OCSP. There are several places in 5280 
where the principle author bends over backwards to be as accommodating 
as possible.
>> The RPKI requires CAs to publish CRLs, and it states where the CRLs
>> are to be published in the repository system (RFC 6480).
> The RPKI can be changed based on implementation and operational
> experience. This ought to be done in a backwards compatible way, of
> course, for instance by still requiring the publication of CRLs but
> not considering them in validation of in-repository signed objects.

I agree that operational experience is an important factor in deciding 
how to evolve the RPKI specs. But, I don't believe that some sloppy 
practices by some CAs should cause us to make major changes. In the Web 
PKI we have had a lot of cases where CAs have failed to behave properly, 
e.g., not issuing CRLs in a timely fashion. For a long time browsers, 
the principle RP software in this context, were content to ignore such 
errors. Fortunately, most browsers not provide warnings and require 
explicit user actions to override these errors. As a result, I think the 
cognizant CAs have become better.

>>>>> If the aim is to avoid risking accidentally marking routes as
>>>>> invalid, this should probably also extend to all information
>>>>> published by child CAs.
>>>> is the concern here that ROAs issued by a subordinate CA might be
>>>> treated differently if there is a missing ROA associated with the
>>>> parent?
>>> I was thinking of the possible case that the parent issues a ROA
>>> for a resource but also delegates it to a child CA which then issues
>>> additional ROAs for the same resource. If the parent ROA is missing,
>>> you cannot rule out that the was indeed the case, so in order to be
>>> safe, you’d have to discard all ROAs for prefixes associated with
>>> the parent.
>> So, the parent issues a ROA binding a range of addresses to an AS
>> that the parent holds. But then  the parent delegates the same range
>> to a child, which is free to bind the addresses to a different AS
>> (that the child holds). Thus a route advertising either AS as the
>> origin is valid. If the parent's ROA is missing, the AS bound to it
>> is no longer considered valid, but the child's ROA is. So, why does
>> one have to discard/ignore all other ROAs associated with the parent?
> Because if the actual route is from the ASN authorised by the child,
> the announcement suddenly becomes invalid instead of unknown. Given the
> operational split between object creation and object publication, it
> doesn’t necessarily have to be the fault of the child that that
> happened.
OK, I see your point.
>>>>>> 3.Manifest present, but invalid
>>>>> The entire PP is ignored.
>>>> So, it's OK to ignore a CRL that is invalid, but not a manifest.
>>>> Personally I believe that if a CA cannot manage to correctly
>>>> generate both a CRL and a manifest, it has a serious operational
>>>> problem.
>>> Indeed. However, bugs exist and unexpected things have a tendency to
>>> happen. I still fail to see how, given a strict adherence to the
>>> manifest, the CRL provides additional value for objects published
>>> within the RPKI repository. So for robustness, it may indeed be
>>> preferable to remove this additional possibility for breakage.
>> As I noted in my reply to Tim a while ago, if we want to view the
>> manifest as the only critical determinant of whether a cert is
>> revoked, then why bother checking the validity interval for the EE
>> certs?
> The same reason we check them with CRLs: the possibility of replay
> attacks of the revocation source.
> Using the manifest for revocation has the exact same issues as using a
> CRL. All it does is drop the need to maintain two objects instead of
> one.
I don't think your argument above is sound. My point is that the 
argument for ignoring CRLs (or not generating them) is that one wants to 
avoid redundant checks, because a CA might fail to correctly maintain al 
of the signed objects that it generates. That argument could equally 
well be applied to checking the validity interval for the EE cert in a 
ROA. This is not a replay issue; a valid, current manifest can be used 
to verify that each ROA, including the embedded EE cert, is intact and 
>>> If the manifest takes over the CRL’s responsibility of expressing
>>> revocation, you’d open a window to replay revoked objects. So this
>>> translates to the question: What would you do today for a stale or
>>> missing CRL?
>> I don't understand your example. If a manifest trumps a CRL, then
>> revoked objects would not appear on a current manifest and so replay
>> of such objects would be ignored, right?
> The question was about _today_, as in with the current situation where
> a signed object’s certificate remains valid even if the object dropped
> off the manifest, what do you do if a current CRL cannot be obtained?
Some additional context is needed. If a cert has not expired, and if one 
has a current CRL, then the cert is valid irrespective the presence or 
absence of the corresponding signed object in a manifest. However, if 
the corresponding signed object is absent from tghe current manifest, 
then an RP should not rely on that object.
> The mechanism from RFC 5280 specifically states that it relies on you
> being able to get the current CRL, so it cannot be used at all in this
> case.
Ah, you've added the detail that a not stale CRL is unavailable. In that 
case the cert cannot be validated and should be ignored.
> What would your guidance be to me as an implementer of a relying
> party software today? Even if I allow users of my software to choose
> what to do (aka "local policy"), I need to pick a default that pretty
> much everyone will then use.

If an RP does not have access to a not-stale CRL for a CA then the RP is 
unable to validate any certs that would have appeared on the CRL. So, 
all signed products of the CA in question ought be rejected.