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
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
$Id$ -*- Text -*-
Python RPKI production tools.
Requires Python 2.5.
See doc/Installation for installation instructions and required
packages.
$Revision$
TO DO:
* Rework handling of surprising responses to up-down requests.
Right now we get confused when we find that parent has issued
a cert that we don't remember requesting, even when we have
the ca_detail object in question sitting in our SQL as
pending. This can happen if we throw an exception later and
don't clean up properly -- which should never happen, but
let's try to be robust about this.
So we need to be smarter about comparing our own state with
what we get back from our parent and figuring out what to do
next. We probably also need to commit changes to SQL earlier.
In general we should never have more than one ca_detail in
state pending for a given ca, but the current code blindly
assumes that will never happen and never recovers if that
assumption has been violated.
STATUS: Not started.
* Use a ticket system instead of trying to track work items in
this README file and archived messages from the testbed list?
STATUS: I have a trac instance, Randy has an RT instance, just
need to decide whether to do something about this, pick one,
and move on.
* Error handling: make sure that exceptions map correctly to up-down error
codes, flesh out left-right error codes. Note that the same exception may
produce different error codes depending on which up-down PDU we're
processing (sigh).
Will require code audit for coherency, which is most of the work.
TIME REQUIRED: Two weeks
DEPENDS ON: almost everything else, as almost any code change
can raise new exceptions that we'd need to handle.
STATUS: Not started
* db.commit(), db.rollback(), code audit for data integrity issues, fix any
data integrity issues that turn up. Among other issues, need to handle loss
of connection to database server and other MySQL errors. Need to be careful
about recovery action depending on whether we had uncommitted changes.
TIME REQUIRED (commit and rollback): 3-4 weeks
TIME REQUIRED (data integrity audit): 1 week
TIME REQUIRED (fix data integrity): Unknown, depends on code
audit and results of runtime testing.
DEPENDS ON: async tasking model rollback.
STATUS: Not started
* Resource subsetting (req_* attributes in up-down protocol), full
implementation. Requires expanding SQL child_cert table to hold subset
masks and rewriting a fair amount of code.
TIME REQUIRED: 3-4 weeks
STATUS: Not started
* Performance testing. Some very preliminary tests show a
hotspot in the TLS code, but further testing will be needed,
particularly after the async tasking model change.
STATUS: Barely started
* Clean up rootd.py to be usable in a production system. Most
urgent issues are handling of private keys, publishing outputs
in pubd, and reissuing when details or keys change. May not
need much else, as this is not a high-traffic server.
TIME REQUIRED: One week
STATUS: Not started
* Update internals docs (Doxygen). Mostly this means updating
function comments in the Python code, as the rest is
automatic. May require a bit more overview text to explain
the workings and usage of the code.
TIME REQUIRED: One week.
STATUS: Ongoing
* Add HSM support. Architecture includes it, current code does
not. First step here would be talking to somebody with strong
understanding of PKCS# 11.
TIME REQUIRED: Unknown
STATUS: Not started
* Installation packaging, so that rpkid can be built and installed like a
normal package.
TIME REQUIRED: One week, longer if installation for many platforms is
required
STATUS: Not started
* Tighten up syntax checking in left-right schema.
TIME REQUIRED: One day.
STATUS: Not started
* rcynic handling of RPKI trust anchors does not yet match most
recent agreement by design team. Currently waiting for an OID
assignment for the CMS-wrapped indirection format that the
design team settled on.
TIME REQUIRED: Three days
DEPENDS ON: OID assignment
STATUS: Not started
* Publication protocol ACL checking may need revisiting. Tricky
bit is making sure that repository receives enough information
to know whether parent has authorized child to use parent's
namespace in nesting case; in theory this is straightforward
but requires careful checking. Current implementation just
uses a configured path check and does not attempt to trace
back to permission from parent in nested publication case.
Class and method design is intended to make it easy to drop in
additional checks if needed.
STATUS: Trivial version (required path check) done.
* Investigate using EKU (RFC 3280 4.2.1.13) as an alternative to
wiring in BPKI EE certs for left-right protocol.
STATUS: Not started
* Testing of this by anybody but the author and a few friends is
going to require some kind of user interface. Python based
web UI is probably the most cost effective approach, Django
might be a good base for this. Some of the operations
suggested in an initial brainstorming session on this are
outside the scope of what rpkid currently knows how to do (eg,
signing S/MIME "please route" messages), so one of the tasks
here is to see if trying to write a user interface sheds light
on required features that are currently missing.
STATUS: CSV file based UI done and documented, perhaps usable.
Django web UI for hosted case under development by a
friendly Django wizard, current design has it just
doing UI and I/O with its own SQL data, so will need a
tool to sit between Django's SQL and our code.
* At present there is no mechanism by which an IRBE could
request signing of objects other than ROAs. Eg, there has
been some discussion of signing S/MIME letters to humans
asking for routing, as an alternative to ROAs. If we decide
to support this at all, it turns into a generalization of the
ROA problem, and suggests that perhaps ROA generation should
be handled somewhere outside of rpkid and only passed to rpkid
for signing. This would be a significant change to the
architecture, as it would remove rpkid's responsibility for
keeping ROAs up to date.
STATUS: Not started
|
