-- $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
}