;;; -*- Lisp -*- ;;; $URL$ ;;; $Id$ ;;; ;;; Scratch pad for working out API design for RPKI engine. ;;; ;;; This file is psuedocode, I just wanted to take advantage of ;;; emacs's built-in support for languages with reasonable syntax. ;;; ;;; Terminology: ;;; ;;; - IRBE: Internet Registry Back End ;;; ;;; - RE: RPKI Engine ;;; Current problems: ;;; 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. ;;; ;;; Might it help to have per-parent config for this, since we have to ;;; config parents anyway? That'd give us the head of the publication ;;; URI, leaving us to figure out just the tail. Could gensym name ;;; tail for dynamically created CAs, could take name tail from chat ;;; with parent (risky? evil parent gives us dangerous name?), could ;;; take name tail from local config but it's hard to see how. ;;; ;;; We now think that there's a negotiation involved here with both ;;; the parent and the publisher. The publication URI directory ;;; breaks into three pieces: head/middle/tail/. head comes from the ;;; publisher, middle comes from the parent, and tail comes from this ;;; RE. head is just the prefix for where we're allowed to put stuff ;;; within the publication repository; this could be configured by the ;;; IRBE or we could ask the publication repository, we currently ;;; think the latter is better. Middle comes from this RE's parent, ;;; and should be a new attribute in the up-down XML protocol: it's ;;; the parent's advice on where to put this particular CA's outputs ;;; in order to get the nice hierarchical properties we want. Tail is ;;; something this RE comes up with, it's per-CA, and all that really ;;; matters is that it's stable; it could be gensymed, or could be our ;;; internal name for the CA, whatever. This hack may require finding ;;; out the parent's publication URI (which we might get from the ;;; parent's cert or not to be decided later), sort this out later. ;;; ;;; If there is any preliminary negotation with publisher before ;;; publication, it is all hypothetical and assumes that proof will be ;;; given with actual publication request. Thing that needs to be ;;; proven is that publication client A is not stepping on publication ;;; client B even when B is A's parent. ;;; Perhaps "cust-id" is really a bad choice, as we have two different ;;; models in which it means different thigs. In this model the ;;; cust-id is the entity which is executing, which is -issuing- ;;; stuff. In the other model, cust-id refers to the entity to which ;;; we are issuing, which is a subject-id; in the terms used below, ;;; this is a child-id. We probably need better names, because people ;;; keep getting confused by this conflict. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; Protocol operations between IRBE and RE. ;;; ;;; This is really two separate protocols over channels that might or ;;; not be the same. Both are client/server protocols, but for some ;;; the RE is the client and for others the IRBE is the client. ;;; ;;; This set of operations are initiated by the IRBE. ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (create-cust-id) => (customer-id) (destroy-cust-id :cust-id 42) => () (list-cust-ids) => (customer-id ...) ;; RobK wonders whether there needs to be an operation that blows away ;; most of the context but preserves things like audit logs. No ;; current consensus on need for this. (get-preference :cust-id 42 :preference-name :favorite-color) => ("obsidian") (set-preference :cust-id 42 :name :favorite-color :value "obsidian") => () ;; Extensions might also show up as preferences that nobody but this ;; IRBE operator has ever heard of ;; This creates both a context and a keypair. Do we need to specify ;; what kind of key in addition to length? (create-biz-signing-context :cust-id 42 &optional :key-type :rsa :key-length 2048) => (biz-signing-context-id pkcs10-cert-request) (destroy-biz-signing-context :cust-id 42 :biz-signing-context-id biz-context-id) => () (list-biz-signing-contexts :cust-id 42) => (biz-signing-context-id ...) (get-biz-signing-certs :cust-id 42 :biz-signing-context-id splat) => (cert ...) (set-biz-signing-certs :cust-id 42 :biz-signing-context-id splat (cert ...)) => () (create-parent-context :cust-id 42) => (parent) (destroy-parent-context :cust-id 42 :parent foo) => () (list-parents :cust-id 42) => (parent ...) (set-parent-ta :cust-id 42 :parent foo :ta ta) => () (get-parent-ta :cust-id 42 :parent foo) => (ta) (set-parent-uri :cust-id 42 :parent foo :uri uri) => () (get-parent-uri :cust-id 42 :parent foo) => (uri) (set-parent-biz-signing-context :cust-id 42 :parent foo :biz-signing-context foo) => () (get-parent-biz-signing-context :cust-id 42 :parent foo) => (biz-signing-context) (create-child :cust-id 42) => (child) (destroy-child :cust-id 42 :child bar) => () (list-children :cust-id id) => (child ...) (get-child-id :cust-id 42 :child foo) => (child-id) (set-child-id :cust-id 42 :child foo :id bar) => () (set-child-ta :cust-id 42 :child foo :ta bar) => () (get-child-ta :cust-id 42 :child foo) => (ta) (set-child-biz-signing-context :cust-id 42 :child foo :biz-signing-context bar) => () (get-child-biz-signing-context :cust-id 42 :child foo) => (signing-context) ;;; The following repo stuff is now wrong, need to come back to it (set-ca-repo-ta :cust-id 42 :ca foo :ta ta) => () (get-ca-repo-ta :cust-id 42 :ca foo) => (ta) (set-ca-repo-uri :cust-id 42 :ca foo :uri uri) => () (get-ca-repo-uri :cust-id 42 :ca foo) => (uri) (set-ca-repo-biz-signing-context :cust-id 42 :ca foo :biz-signing-context foo) => () (get-ca-repo-biz-signing-context :cust-id 42 :ca foo) => (biz-signing-context) (please-run-this-cust-id-now :cust-id 42) => () (please-publish-world-right-now :cust-id 42) => () ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; Protocol operations between IRBE and RE. ;;; ;;; This is really two separate protocols over channels that might or ;;; not be the same. Both are client/server protocols, but for some ;;; the rpki engine and for others the irbe is the client. ;;; ;;; This set of operations are initiated by the RE. ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (list-resources :cust-id 42 ; issuer id &optional ; If left off, we're asking about self rather than child :child id) ; subject id => ((:ipv4-address "10.0.0.44/32" "10.3.0.44/32") (:ipv6-address "fe80:dead:beef::/24") (:as-number "666") ...) (list-rights-to-route :cust-id 42) ; Self => ((as-number :ipv4 prefix-or-range :ipv6 prefix-or-range ...) (as-number "ipv6 prefix-or-range :ipv6 prefix-or-range :ipv4 prefix-or-range ...) ...) (report-error :cust-id 42 :error-token :your-hair-is-on-fire :bag-of-data whatever) => ()