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
|
-- $Id$
-- Copyright (C) 2007-2008 American Registry for Internet Numbers ("ARIN")
--
-- Permission to use, copy, modify, and distribute this software for any
-- purpose with or without fee is hereby granted, provided that the above
-- copyright notice and this permission notice appear in all copies.
--
-- THE SOFTWARE IS PROVIDED "AS IS" AND ARIN DISCLAIMS ALL WARRANTIES WITH
-- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-- AND FITNESS. IN NO EVENT SHALL ARIN BE LIABLE FOR ANY SPECIAL, DIRECT,
-- INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-- LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-- PERFORMANCE OF THIS SOFTWARE.
-- Signed manifests for RPKI repositories. Relying parties use object
-- (as opposed to channel) security for everything in this design
-- repository, which is the right thing to do for various reasons but
-- leaves us open to attacks which intercept the rsync connection and
-- drop valid objects out of an SIA collection. At present this is
-- not detectable, so we need a mechanism.
--
-- Manifests as described here are modeled on CRLs, because the issues
-- involved in detecting stale manifests, manifest replays, etc are
-- similar to those for CRLs. So we want many of the fields that a
-- CRL has. Syntax differs, though, since RPKI repositories can
-- contain objects not covered by CRLs (eg, ROAs), and reuse CMS as
-- the manifest signature format rather than inventing another one.
--
-- See RFC 3280 section 5 for CRL layout and extensions.
--
-- We're only trying to cover objects in the same SIA collection
-- (directory) as the manifest. We will probably want to name the
-- manifest itself with a name derived from the g(ski) of the cert of
-- which this is the SIA collection. We'll need an EE cert to sign
-- the manifest; the EE cert should probably just use RFC 3779
-- inheritance to cover all the resources that its issuer holds. If we
-- use CMS, we might just want to include the EE cert in the CMS
-- bag of certs.
--
-- Lisp pseudo-code version of my original proposal for what goes
-- inside the CMS wrapper:
--
-- (manifest :version 1
-- :collection-uri "rsync://foo.example/wombat/"
-- :this-update timestamp
-- :next-update timestamp
-- :manifest-serial 17
-- :hash-algorithm :sha256
-- (:name foo.cer :hash aabbccdd...)
-- (:name bar.cer :hash bbccddee...)
-- (:name foo.roa :hash ccddeeff...)
-- (:name baz.crl :hash ddeeff00...)
-- ...)
--
-- Steve Kent came up with something very similar in ASN.1. At this
-- point I think that Steve and I have converged, so here is Steve's
-- ASN.1, which, absent new issues, I expect to implement with
-- OpenSSL's ASN.1 engine.
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0, -- first version is 0
manifestNumber INTEGER, -- to identify unscheduled manifest issuance
thisUpdate GeneralizedTime, -- this manifest issuance time
nextUpdate GeneralizedTime, -- next scheduled manifest issuance time
fileHashAlg OBJECT IDENTIFIER, -- algorithm used to generate file content hash values
fileList SEQUENCE OF FileAndHash -- list of file name and content hash pairs
}
FileAndHash ::= SEQUENCE {
file IA5String -- file name
hash BIT STRING -- hash of file content
}
|
