Re: [Rescert] Draft of signed manifest design

[Stephen Kent <kent@bbn.com>]

Rob,

I set off to create a manifest syntax in ASN.1, after our meeting in 
Tallin.  I sent a copy to Geoff, who noted a possible omission, and 
then I sent a message noting what I think needs to be done, in terms 
of manifest processing (not just syntax) to ensure security.  My 
proposed  syntax and my security discussion is included below.

Iyr syntax looks very similar in several respects. We both have 
borrowed the CRL this/next update model, and a serial number to 
detect unscheduled manifest issuance. We also both noted the 
opportunity to use CMS as the signature format and to carry the EE 
cert there.  The only differences I see are:
	- you list a file name and a hash of the file name, whereas I 
list URIs.

Steve
------

The manifest is carried in a CMS wrapper, and that wrapper can carry 
the EE cert needed to verify the manifest, so we don't have to make 
explicit provision for carriage of that EE cert (or a pointer to it) 
in the manifest ASN.1


Manifest ::=    SEQUENCE {
        version         INTEGER DEFAULT 0, -- to allow for future versions

        manifestNumber  INTEGER, -- to identify manifests issued 
between scheduled -- issuance dates
        thisUpdate      GeneralizedTime, -- date and time this 
manifest was issued
        nextUpdate      GeneralizedTime,  -- date and time of next 
scheduled manifest
        certfiles       SEQUENCE (SIZE (1..MAX)) OF IA5String,
                           -- list of one of more URIs for cert files
        cRLfiles        SEQUENCE (SIZE (1..MAX)) OF IA5String,
                                  -- list of one or more URIs for CRL files
	rOAfiles        SEQUENCE (SIZE (1..MAX)) OF IA5String OPTIONAL
                              -- list of one or ore URIs for ROA files
                        }

It's necessary but not sufficient to verify the signature on a 
manifest using an EE cert that traces to a trust anchor. Let me 
explain why, usng an example.

A relying party will process a set of manifests it has retrieved from 
the repository system. It could encounter two manifests that refer to 
the same place in the repository. Each has a different signer and 
each enumerates different contents for the repository location in 
question. The signature on both manifests will be verifiable using 
(EE) certs that verify under the PKI. How does the relying party now 
which manifest is valid? It is not enough to compare a URI against 
the SIA value in the EE cert used to verify the manifest signature, 
because that is completely under the control of the CA that issued 
the EE cert, i.e., an ISP can generate any cert it wishes, subject to 
the 3779 constraints.

This suggests to me that an RP will not be able to detect a bogus 
manifest just based on the usual PKI checks. Instead, the RP will 
have to verify that the certs, CRLs, and ROAs listed in the manifest 
can be verified using the CA cert for the EE cert used to verify the 
manifest.  This check prevents one registry/ISP from generating a 
manifest that covers certs (and CRLs and ROAs) associated with a 
different registry/ISP. It also says that we want ALL CAs to generate 
manifests, so that RPs will look for them at every CA-point in the 
hierarchy and be suspicious if a manifest is missing.

We might omit CRLs from manifests, because the extant NextIssueDate 
mechanism in a CRL will detect a missing, scheduled CRL. However, 
including CRL files in manifests does have the advantage of allowing 
one to detect a deleted, unscheduled CRL, which is a nice feature. I 
also thought about omitting ROA files, because of the 1-to-1 
correspondence with the EE certs used to verify them, but since we 
are adding EE certs for manifest verification, and may add EE certs 
for other functions, I dropped that attempted efficiency.

Steve