On Dec 2, 2011, at 2:51 AM, Danny McPherson wrote: > > On Nov 30, 2011, at 10:38 AM, Andrew Chi wrote: > >> The specs leave room for the relying party to decide what to do with >> imperfect but not completely invalid objects. > > Thanks for sharing Andrew. One question and one comment... > > Is an expired object "completely invalid" or just "imperfect"? Can you > explain the difference?
I think that here, the term 'stale' is preferred over 'expired'. This is not about any object type, but manifests and crls in particular.. A manifest is stale "if the current time is after the nextUpdate time": http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-16#section-6.4 When a one-time-use EE cert is used in the manifest CMS the validity time MUST match the 'thisUpdate' and 'nextUpdate' of the manifest contents: http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-16#section-5.1 So note that in this case the 'expired' EE cert should be considered 'stale' instead as well.. CRLs also have a 'nextUpdate' field, that's typically the same as the manifest's. Again, these are considered 'stale' not 'expired' after this time. The reasoning is that an RP may only have old data for some reason: eg. no updates occurred due to some technical issue, or there is some problem retrieving new info. In this case it would be a bit rash to *reject* the manifests and CRLs and all objects that depend on them. This is the text in http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-16#section-6.4: "All signed objects at the publication point issued by the entity that has published the stale manifest, and all descendant signed objects that are validated using a certificate issued by the entity that has published the stale manifest at this publication point SHOULD be viewed as somewhat suspect, but MAY be used by the RP as per local policy." Current validator implementations differ in how they treat this case: rsynic accepts for indefinite(?) time (warns?)* BBN validator accepts for indefinite(?) time (warns?)* RIPE NCC val. rejects *: Andrew, Rob please comment.. We are now changing our validator to do the same as the other implementations and accept stale manifests and crls for an indefinite time, but warn about it. There still is something to say for not accepting 'stale' for too long. It makes an RP vulnerable to replays and defeats the idea of why the manifests and crls are there in the first place, in my opinion. So, we are thinking of adding a configuration setting at some point that allows the user to indicate something like: "accept stale for a maximum of X times the intended validity period" -- with a default of 3(?).. so: if a manifest/crl was issued with an intended 24 hour life time, accept it for another 72 hours. As a compromise between security and resilience.. I am open to better suggestions.. Note that if other objects such as CA certificates, or ROAs (by their EEs) are expired they must be rejected. The validator implementations agree on this. > > In general, I agree with you that this needs to be codified before we proceed > and I agree with Randy that "I see no reason to tolerate useless > incorrectness" > in a brand new security system expressly aimed at bringing integrity to the > mix, > integrity that is especially important in times of instability and > uncertainty. > I think corner cases exist where a publisher doesn't follow the standards strictly, but the offense is not so serious that a publication point and its descendants should be rejected altogether. For example the AIA pointer is not really needed to validate the child certificate. Incorrect key usage bits in an EE cert is another (our old code had this bug). Other current example: illegal characters in subject names. It's all incorrect, but none of these case actually make it impossible to validate a child cert. The AIA pointer is not needed when you're walking top-down, the key usage bits are an indication of allowed use, but not used to determine validity (esp. in EEs an entity issued themselves, it's not their parent allowing/disallowing some use), the subject still parses in the BBN, openssl (rsynic) and bouncy castle (our validator uses this) libraries. So.. I would actually prefer to warn instead in cases like this. As an implementer of publishing software I want to fix my code to not raise any of these warnings. But resource competition means that this may take time.. Therefore I think that at the very least validators should *warn* for new corner cases for some time before they start to reject. There are a number of different implementations out there and not all corner cases are covered. If validators start checking for more and more corner cases now, and reject, that would result in very flaky availability (in terms of acceptance) of the current repositories. Having a list of all these corner cases and their agreed severity can help prevent nasty surprises. Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
