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
|
$Id$
Python RPKI production tools.
Requires Python 2.5.
External Python packages required:
- lxml, which in turn requires the libxml2 C libraries.
FreeBSD: /usr/ports/devel/py-lxml
- MySQLdb, which in turn requires MySQL client and server. I'm
testing with MySQL 5.1.
FreeBSD: /usr/ports/databases/py-MySQLdb
- TLSLite, which pulls in other crypto packages.
FreeBSD: /usr/ports/security/py-tlslite
- Cryptlib, at the moment just to support TLSlite but may end up using
it for other things later.
FreeBSD: /usr/ports/security/cryptlib
...but the FreeBSD port doesn't (yet?) install the Python bindings,
sigh, so at the moment you have to do that by hand:
# cd /usr/ports/security/cryptlib
# make install
# cd work/bindings
# python setup.py install
# cd ../..
# make clean
- Eventually I expect that this will require an event-handling package
like Twisted, but I'm not there yet.
We also use a hacked copy of the Python OpenSSL Wrappers (POW)
package, but our copy has enough modifications that it's expanded in
the Subversion tree. Depending on how this all works out, I may end
up splitting the POW.pkix module out of the POW package and using it
with Cryptlib, as the POW.pkix package is 98% about doing ASN.1 in
pure Python and only 2% about any kind of crypto.
To do list:
- timestamps are a mess. we have four different kinds already:
seconds from epoch, the the two flavors of timestamps used
in asn.1, and the timestamps used in mysql. need a
unifying class to hide all this nastiness.
- publication protocol and implementation
- manifest generation
- subsetting (req_* attributes in up-down protocol)
- revocation and crl generation
- need to keep data on unexpired revoked certs to generate crl
- ever need to delay revocation of old certs to give their
replacements time to propegate?
these two may imply that we need more fields in child_cert table to
indicate whether a cert is dead, eg, a date field which is NULL if
the cert is still live, otherwise is the date after which it should
be in the crl
- publication hooks everywhere - need not wait for protocol, can just
log what would happen for now
- cert publication
- crl publication
- manifest publication
- withdrawal of all of the above
- child batch processing loop, eg, regeneration or removal of expired
certs, crl and manifest update, etc
hmm, should this be an iteration over child_cert objects or over ca
objects? probably the latter as the ca is the actor in pretty much
everything that might need to be done
figuring out whether to regenerate or remove expired certs requires
some of the same data as crl generation
- tiny up-down root server -- no sql or left-right needed, just config
file, http server, static root cert and key. in theory this should
just be a matter of subtyping the main up-down code while overriding
the serve_pdu() methods.
things we'd need in a config file for this:
- the one and only issuer cert (self-signed in this special case)
- the one and only issuer private key id
- filename in which to store the one and only subject cert
- bsc info for one and only child
- https server key and cert
- validity interval to use when issuing
- publication urls for issuer cert, subject cert, crl, and manifest
- https and cms data for publication server
- resources to issue? or just copy/inherit from self-signed?
- Haven't done anything about db.commit() and db.rollback() yet, for
that matter haven't yet whacked MySQL to enable those features.
- Access to object data attributes really ought to be through accessor
methods so that the .set() method can set the sql_dirty flag
automagically. Not done yet.
- Hmm, I seem to have goofed on the bsc table, need a column for the
hash algorithm after all, as it's not intrinsic to the key. Probably
ought to let it be set independently of the key too. But for the
moment I'm only supporting 2048-bit RSA with SHA-256 digests, so
fixing this is not urgent.
|
