Re: [Sidrops] trying to limit RP processing variability

[Martin Hoffmann <[e-mail]>]

Stephen Kent wrote:
> > Stephen Kent wrote:  
> >>                                      *Overview *
> >>  
> > [...]  
> >> *Terminology*
> >>
> >> Missing: an object named in a Manifest, but not available for
> >> download from a PP, is termed *missing*. An RP has no obvious way
> >> to acquire missing objects, but operators SHOULD be warned about
> >> which objects are missing.  
> > Since "missing" seems to be the opposite of the "present" in the
> > case overview below, I think we need to more precisely define the
> > meaning for both manifests and CRLs.
> >
> > I would define the meaning of "manifest missing": the manifest
> > referenced in the CA certificate is not available for download from
> > a PP. That leads to the case where there is a valid manifest at the
> > PP but it is not the one on the CA certificate.
> >
> > "CRL missing" is a little more complicated, since there is two
> > places where CRLs are referenced: in the manifest and in the EE
> > certificates of signed objects. So we also have the case where a
> > CRL in an EE certificate isn’t actually mentioned in the manifest.  
> 
> I don't think I follow your reasoning here.
> 
> For CA A, there is one PP where all of the signed objects issued by A 
> live, ignoring the cases of key rollover or algorithm transition 
> (Section 2 of RFC 6481, especially Figure 1). This PP contains the
> ROAs, a manifest, and a CRL, router certs, and any subordinate CA
> certs. The CRL that lives here would contain an entry for a cert
> associated with a manifest if that cert were revoked, and the
> manifest contains an entry for the CRL. If one were to encounter a
> CRL that contained an entry for the EE cert in the manifest, that
> would indicate an error by the CA.

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.

So, when validating the EE certificate of a signed object, the CRL
could be missing in the manifest and it could be present in the
manifest but missing in the sense that it can’t be downloaded from the
publication point.

I think this is a case worth clarifying since it seems to currently be
left to local policy.

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

> > In order to avoid using partial sets of information, the entire
> > content of the PP is ignored if any object is missing, corrupted,
> > or invalid.  
> This is not consistent with your suggestion that the CRL can safely
> be ignored.

Sorry, indeed. Any signed object or certificate.

> > Presumably this chould only be limited to objects of the same type,
> > i.e., if there is a least one missing, corrupted, or invalid ROA,
> > discard all ROAs.  
> I'm not sure why the group-oriented approach is useful, expect
> perhaps for ROAs. Why would one elect to ignore some router certs if
> one were missing?

Hm, true. So perhaps this should be defined per object type? For ROAs
(and in the future ASPAs) partial sets cause hard to debug issues
whereas for router keys and ghostbuster records, having to discard
single objects of a set shouldn’t cause any harm.

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

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

> > This essentially ignores the CRL for any object published within the
> > repository and essentially moves its role over to the manifest. The
> > CRL would still be considered for objects published outside the
> > repository, such as the proposed Resource Tagged Assertions.  
> 
> A missing manifest is a serious concern, but I would consider using 
> cached, still valid objects for the PP, and insisting on contacting
> the CA or PP maintainer.

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?

Kind regards,
Martin