aboutsummaryrefslogtreecommitdiff
path: root/scripts/regeng-api
diff options
context:
space:
mode:
Diffstat (limited to 'scripts/regeng-api')
-rw-r--r--scripts/regeng-api21
1 files changed, 21 insertions, 0 deletions
diff --git a/scripts/regeng-api b/scripts/regeng-api
index dbec3327..d1030a89 100644
--- a/scripts/regeng-api
+++ b/scripts/regeng-api
@@ -12,6 +12,26 @@
;;;
;;; - RE: RPKI Engine
+;;; Current problems:
+;;;
+;;; Model below is still wrong, although converging on the right
+;;; thing. Children should not be bound within CAs, and CA's can't be
+;;; created until we poll parent to find out what to create; CAs need
+;;; to be created on the fly. Children should be business
+;;; relationships, not per-CA things. parent operations should be per
+;;; customer not per ca.
+;;;
+;;; Need revoke and rekey operations.
+;;;
+;;; And, er, how do things like publication URIs (which also go into
+;;; some of the X.509 extensions in the resource certs) get into the
+;;; RE anyway? This is close to being the same question as how do we
+;;; configure the publication point, as the data are largely the same.
+;;; Part of the problem is that, if we create CAs on the fly in
+;;; response to what we learn from our parent, how do we map that to
+;;; any kind of preconfigured data on where we should publish? This
+;;; is a mess.
+
;;; Protocol operations between RE and signing engine. This assumes
@@ -200,6 +220,7 @@
=> (biz-signing-context)
(please-run-this-cust-id-now :cust-id 42)
+=> ()