This document describes an alternative *implementation* strategy for gathering policy information from a certification path.  The intent is to avoid gross inefficiencies in the suggested approach in RFC 5280, which can be exploited for DoS attacks.

Overall, the algorithm changes are very clearly explained, with helpful diagrams.  I found the introductory material lacking though.  This is a very hard document to process.  And I have a fair bit of relevant context already.

Let me start with a misapprehension I had when reading this...

The intent is to produce the same outcome as the original algorithm.  However, it was not initially clear to me that the output of this algorithm is identical.  The policy mappings appear to be fine, but the way in which qualifier propagate does not appear to be entirely consistent.  The main difference between the graph and tree representation is that the graph consolidates nodes.  In a graph, upward paths from leafs to the root will traverse the same intermediate nodes, causing the set of qualifiers to be consistent.  A tree structure appears to allow for paths through different nodes, which perform the same policy mappings, but might have different qualifiers.

Now, I believe that this is an impossible outcome.  The tree version will have the same qualifiers on nodes with the same mapping, because they come from the same place (the single certificate at that depth).  The graph version avoids replicating these nodes (another minor source of inefficiency).  However, because there is a lot of talk about different paths, it is easy to get confused and think that maybe nodes come from different certificates.  That is, I think.  Because it seems possible for a certificate to contain multiple mappings for the same OIDs, with different qualifiers for each mapping.  I don't think that changes the outcome either, but it is a bit of a mind-bender, head-scratcher if you don't have a lot of time or context.

This problem is, I think, something that could be helper with better introductory material.  The amount of assumed knowledge is very high, particularly given the nature of RFC 5280, which is one of the most arcane and unwelcoming documents the IETF has ever produced.  A *tiny* bit more context would help make this document far more comprehensible.  (OK, a lot more, because what is there is extremely scant.)

Things that I think would help:

* A clearer explanation of what the goal of algorithm is.  Section 1.1 says that this doesn't change anything, but even RFC 5280 doesn't set out its goals.
* A recognition that this algorithm is applied to a single certification path, or chain of certificates, from a trust anchor to an end-entity certificate.
* An explanation that in this context "policy" is an concept that is represented by an OID, with effect that is defined by understanding the OID.
* A note about qualifiers and the intended effect: that they are specified by each CA certificate and that the final policy is affected by all qualifiers in the certification path.
* A disclaimer that this doesn't help a verifier select between certification paths.  (By the way, there is a bunch of fairly troubling text about picking and choosing paths, which caused my security senses to go on alert, but I assume that this is a pre-existing RFC 5280 thing.)

Nits:

The introduction says "This cost asymmetry", but it really isn't clear what the cost asymmetry it refers to is.

I've opened pull requests for a few very minor things.