1 files changed, 74 insertions, 0 deletions
diff --git a/presentations/signed-manifests b/presentations/signed-manifests
new file mode 100644
index 00000000..d1bd3f5e
--- /dev/null
+++ b/presentations/signed-manifests
@@ -0,0 +1,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
+}