;;; -*- Lisp -*- ;;; $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 ;;; Protocol operations between RE and signing engine. This assumes ;;; the model in which the signing engine stores nothing but keypairs ;;; and takes orders from the RE on what to sign; this still needs to ;;; be checked by competent paranoids. ;; Create a keypair. :length is the number of bits for the key ;; (default 2048?). (create-keypair :cust-id 42 :length 2048) => (public-key key-id) ;; Destroy a keypair. (destroy-keypair :cust-id 42 :key-id key-id) => () ;; List existing keypairs (list-keypairs :cust-id 42) => ((key-id public-key) (key-id public-key) ...) ;; Sign something. how-to-sign tells us both what signature method to ;; use (ie, what kind of object we're signing) and also the signature ;; algorithm to use (where there are multiple choices, which perhaps ;; there should not be?). (sign-thing :cust-id 42 :what-to-sign cert-without-signature :how-to-sign :cert-rsa/sha256 :key-id key-id) => (signed-thing) ;;; 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 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 ;; The following create RPKI CA contexts (create-ca-context :cust-id 42) => (ca-id) (destroy-ca-context :cust-id 42 :ca-id foo) => () ;; This creates both a context and a keypair (create-biz-signing-context :cust-id 42) => (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 ...)) => () (set-ca-parent-ta :cust-id 42 :ca foo :ta ta) => () (get-ca-parent-ta :cust-id 42 :ca foo) => (ta) (set-ca-parent-uri :cust-id 42 :ca foo :uri uri) => () (get-ca-parent-uri :cust-id 42 :ca foo) => (uri) (set-ca-parent-biz-signing-context :cust-id 42 :ca foo :biz-signing-context foo) => () (get-ca-parent-biz-signing-context :cust-id 42 :ca foo) => (biz-signing-context) (create-ca-child :cust-id 42 :ca foo) => (child) (destroy-ca-child :cust-id 42 :ca foo :child bar) => () (list-ca-children :cust-id id :ca foo) => (child ...) (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) (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) ;;; 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 &optional :ca ca) ; If left off, we're asking about self rather than child => ((:ipv4-address "10.0.0.44/32" "10.3.0.44/32") (:ipv6-address "fe80:dead:beef::/24") ...) (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) => () ;;; Repository update protocol. Same basic CMS-signed XML mess we use ;;; elsewhere, this time with RE as client, lodging repository as ;;; server. Authorization is a combination of business key and ;;; resource key/cert: biz key demonstrates that we're authorized to ;;; play with this repository at all, resource cert demonstrates ;;; relationship to the datum to be published. (publish-thing :thing-type :crl :signed-thing signed-thing) => () ;;; Where signed-thing looks like: ;;; ;;; (repo-biz-key-signature ;;; (ca-key-signature ;;; object-to-publish)) ;;; ;;; NB: the ca-key-signature is a simple signature with no ;;; certificates embedded, as we can't assume that the repository ;;; knows the trust anchor. More precisely, if the crypto guys tell ;;; us that we must do cert chain verification here, the business ;;; setup for all this has to make sure that the repository operator ;;; -does- know the RPKI trust anchor and we'd kind of rather not go ;;; there. The repo-biz-key-signature is cms with the full signer ;;; cert chain in the bag plus the resource cert as an extra cert in ;;; the bag. ;;; ;;; SIA in the signing resource cert's tells us where to publish the ;;; object.