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.