Re: [Sidrops] trying to limit RP processing variability

[Martin Hoffmann <[e-mail]>]

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.

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

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

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


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

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

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

Kind regards,
Martin