Subject: [sidr] PKIX Observations on CRL (and Manifest)

From: George Michaelson <[email-masked]>
Date: Wed, 23 Feb 2011 17:57:20 +0800

PKIX is discussing the effect of a missing CRL at the moment.

It appears some people doing relying party tests in 5280 over-interpret the non-availability of a CRL as a hard-fail, and treat the CA products as invalid, in a belief that 5280 requires this of them. 

But, this is not actually required. And in like sense, it would not be required of a manifest.

There are of course certain questions regarding signed products which become unanswerable in the face of not having a manifest, or a CRL, but they are not hard-fails which would invalidate the entire object set, and by extension, the sub-tree of child products ad infinitum.

section 6. Local Cache Maintenance of the ARCH document does place an onus on a cache administrator to review the CRL/Manifest products and detect corruption, but its not presented as a strong/normative validation issue.

Can I ask relying party tool writers to consider this in their tools? Warnings are useful, but over-aggressive pruning or de-validation would not be good.

cheers

-George

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 23 Feb 2011 11:11:16 +0100

Hi,

> Can I ask relying party tool writers to consider this in their tools? Warnings are useful, but over-aggressive pruning or de-validation would not be good.

Yes. Our current implementation is indeed over-aggressive but it's on our list to sedate it.

Cheers
Tim

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 23 Feb 2011 11:26:59 +0100

> Yes. Our current implementation is indeed over-aggressive but it's on our list to sedate it.

Having said that... yes we will sedate it, in particular with regards to *stale* manifests and CRLs which now result in 'invalid'. Missing CRLs I am not sure of yet, but it can be considered.

Missing manifests are problematic. Manifests are required by the res-cert draft:
http://tools.ietf.org/html/draft-ietf-sidr-res-certs-21#section-4.9.8.1

In our implementation we use the manifests to do top-down validation. I.e. for a TA we look in the manifest to find all published objects and child CA certs. The child CA certs have manifests listing their stuff and so on.. This is the easiest way do a recursive top-down validation. (Note that we also pre-fetch the directory for efficiency, but we only process the items listed on the manifest) Since the res-cert draft requires manifests I think this should be okay. If this assumption is wrong, please speak up.. I think, but don't know for sure, that other RP tools are using a similar approach.

Cheers
Tim

---

From: Rob Austein <[email-masked]>
Date: Wed, 23 Feb 2011 13:30:56 -0500

draft-ietf-sidr-res-certs is pretty clear about requiring the
validator to check for certificate revocation, which implies that the
validator cannot proceed without the relevant CRL.

As Tim points out, the effective definition of an object being in the
collection of a certificate's is that it is present in the manifest;
the only other way of defining the product collection even with rsync
is to trawl the directory, which may find other objects, including
objects deliberately omitted from the manifest; with an alternative
protocol such as HTTP (if people are even still thinking about that)
there is no standard way of trawling the directory at all.

So I do not think it makes sense to make the presence of either CRL or
manifest optional in any sense here.

Allowing stale CRL and manifest, sure.  My validator already allows
that, in fact that's the default setting, you have to add explicit
configuration to get it to reject anything just because of stale CRLs
or manifests.  As I think I understand it, this is consistent with the
advice we've gotten for years from the PKI experts.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Feb 2011 16:55:40 -0500

At 5:57 PM +0800 2/23/11, George Michaelson wrote:
>It appears some people doing relying party tests in 5280 
>over-interpret the non-availability of a CRL as a hard-fail, and 
>treat the CA products as invalid, in a belief that 5280 requires 
>this of them.
>
>There are of course certain questions regarding signed products 
>which become unanswerable in the face of not having a manifest, or a 
>CRL, but they are not hard-fails which would invalidate the entire 
>object set, and by extension, the sub-tree of child products ad 
>infinitum.
>
>section 6. Local Cache Maintenance of the ARCH document does place 
>an onus on a cache administrator to review the CRL/Manifest products 
>and detect corruption, but its not presented as a strong/normative 
>validation issue.
>
>Can I ask relying party tool writers to consider this in their 
>tools? Warnings are useful, but over-aggressive pruning or 
>de-validation would not be good.
>
>cheers
>
>-George

The BBN RP software embodies the notion of stale (vs. expired) CRLs 
and manifests. Mark and Andrew are authoritative on this matter, but 
my recollection is that we give the RP knobs to control how they 
choose to deal with stale items, maybe even based on te degree of 
staleness.

Steve

---

From: "Mark Reynolds" <[email-masked]>
Date: Wed, 23 Feb 2011 21:07:40 -0500

>>de-validation would not be good.

BBN's relying party software provides for configuration options that
control how stale objects (CRLs, manifests) or missing objects (manifests)
are treated. The operator can set these is a simple configuration file,
can supply them on the command line, or can rely on the built-in defaults.
Currently, the built-in defaults are the most strict: stale CRLs and stale
manifests are rejected, and missing manifests are right out.

- Mark