Thanks!
I'll take a stab at expanding on the introduction more. Although RFC 5280's obtuseness impacts me just as much as anyone else. This feature is so pointlessly complicated and most of what I understand about it is from trying to working through 5280's incomprehensible algorithm. I understand the "how" pretty well now, but as for the "why", I'm also in the dark. :-)
> 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.
Does that resolve this, or was it something else?
> * 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.)
> 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.)
This is referring to the updates to section 6.1? I think picking paths is mostly outside the scope of this document. All this is within the scope of validating a single certification path anyway. I suppose, if an application wanted to pick paths based on which asserted a particular policy, or even based on policy qualifiers, I suppose that's its business. (Not that I would endorse such a thing either!)
As far as this document is concerned, the only reason I needed to update that paragraph was to strike the reference to the policy tree. :-)
On Thu, Jan 11, 2024 at 6:28 PM Martin Thomson via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Martin Thomson
Review result: Ready with Nits
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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
