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