draft-ietf-lamps-x509-policy-graph is now RFC 9618
I've kept most of the comments in crypto/x509/policy.cc, but since we
now cite a document that defines the policy graph, we no longer need to
justify it in the comment.
Change-Id: Ice83ee436246c06ebd65e6a6e77299e55c2b63dc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81968
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
diff --git a/crypto/x509/policy.cc b/crypto/x509/policy.cc
index 453576a..1e3d406 100644
--- a/crypto/x509/policy.cc
+++ b/crypto/x509/policy.cc
@@ -24,24 +24,18 @@
#include "internal.h"
-// This file computes the X.509 policy tree, as described in RFC 5280, section
-// 6.1. It differs in that:
+// This file computes the X.509 policy graph, as described in RFC 9618.
+// Implementation notes:
//
// (1) It does not track "qualifier_set". This is not needed as it is not
// output by this implementation.
//
-// (2) It builds a directed acyclic graph, rather than a tree. When a given
-// policy matches multiple parents, RFC 5280 makes a separate node for
-// each parent. This representation condenses them into one node with
-// multiple parents. Thus we refer to this structure as a "policy graph",
-// rather than a "policy tree".
-//
-// (3) "expected_policy_set" is not tracked explicitly and built temporarily
+// (2) "expected_policy_set" is not tracked explicitly and built temporarily
// as part of building the graph.
//
-// (4) anyPolicy nodes are not tracked explicitly.
+// (3) anyPolicy nodes are not tracked explicitly.
//
-// (5) Some pruning steps are deferred to when policies are evaluated, as a
+// (4) Some pruning steps are deferred to when policies are evaluated, as a
// reachability pass.
// An X509_POLICY_NODE is a node in the policy graph. It corresponds to a node
diff --git a/include/openssl/x509.h b/include/openssl/x509.h
index ca3942d..52d2b8b 100644
--- a/include/openssl/x509.h
+++ b/include/openssl/x509.h
@@ -2389,7 +2389,7 @@
// suite of related extensions determines the "policies" that apply to a
// certificate path. Evaluating these policies is extremely complex and has led
// to denial-of-service vulnerabilities in several X.509 implementations. See
-// draft-ietf-lamps-x509-policy-graph.
+// RFC 9618.
//
// Do not use this mechanism.