1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
;;; -*- 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
;;; 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.
;;; This would be a trivial protocol, except for two constraints:
;;;
;;; a) In the case where parent and child are sharing a repository,
;;; we'd like to nest child under parent to speed up rcynic.
;;;
;;; b) The repository operator might want to do some checks to assure
;;; itself that what it's about to allow the RE to publish is not
;;; dangerous toxic waste.
;;;
;;; Protocol goals as of last discussion in Prague:
;;;
;;; 1) "Negotiate" publication point URI. This is a bit complex, in
;;; that part of the URI may come from the publication
;;; repository, parts from the RE's parent, and parts from the RE
;;; itself. Some discussion over whether we need online protocol
;;; to negotiate the publication repository's part, no firm
;;; consensus, plurality of the room was leaning towards "no",
;;; ie, the repository's portion of the URI is negotiated via the
;;; business channel and configured into the RE by the IRBE.
;;;
;;; 2) In case where parent and child are in fact sharing repository,
;;; repository operator is responsible for keeping these two users'
;;; naming schemes from coliding with each other. More precisely,
;;; the repository operator is responsible for checking to see that
;;; the parent agreed to let the child publish in a particular
;;; subtree. Fortunately, this is an easy check: the parent has to
;;; issue a cert to the child anyway, and that cert will contain a
;;; signature by the parent over the child's SIA URI, so the
;;; repository just has to check that. For purposes of this check,
;;; the parent's issuing cert (which the repository has, by
;;; definition, since this is the nested hosting case) can serve as
;;; a trust anchor for checking the child's SIA.
;;;
;;; 3) To the extent that the repository operator wants to guard
;;; against toxic waste, it might want to check further up the
;;; resource cert chain, regardless of where the ancestors lodge.
;;; For this to work properly, the repository operator needs to
;;; agree (as part of a business negotiation, probably) with the RE
;;; on which trust anchors the repository should use to perform
;;; these checks; ultimately, this decision (as with any TA choice)
;;; is up to the relying party (in this case the repository
;;; operator), but if there's going to be a problem due to
;;; mismatched TA choices, we would really like to throw the
;;; exception during the business negotiation rather than via a
;;; runtime refusal to publish.
;;;
;;; Note that, in this publication model, any agreement that the
;;; repository makes to publish the RE's output is conditional upon
;;; the object to be published passing all of its checks.
(publish-thing :publication-uri uri-of-thing-we-are-publishing
:signed-thing signed-thing
:credential-certs (cert ....)
:thing-type :crl)
=> ()
;;; signed-thing is an object (certificate, CRL, ROA) signed by the
;;; private key associated with a resource certificate held by the
;;; entity sending the (publish-thing) request.
;;;
;;; credential-certs is a set of whatever resource certificates are
;;; needed to demonstrate to the repository engine that the entity
;;; requesting publication is making a legitimate publication request.
;;; Goal (2), above, requires the requestor to supply the resource
;;; certificate chain up to the parent to demonstrate that the parent
;;; has approved (signed) the requested SIA. Goal (3), above, would
;;; require supplying the cert chain back to some resource trust
;;; anchor established as part of the business relationship between
;;; requestor and repository operator.
;;;
;;; Thing type...was present in a previous version of this protocol.
;;; I'm not sure we need it, am not sure we don't.
|
