Re: [Sidrops] trying to limit RP processing variability

[Stephen Kent <[e-mail]>]

Martin,

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

Steve