Manifests (and Destiny?)

1. Manifests(and Destiny?) Stephen Kent BBN Technologies

2. What’s a Manifest? • A manifest is a signed object listing all of the signed objects issued by an authority responsible for a publication point in the repository system. • The purpose of a manifest is to allow a relying party to detect and reject attacks that seek to delete entries from the repository, or to replace a current entry with an older, valid instances of an entry.

3. Repository Redux • The RPKI repository system consists of a tree of publication points • For most publication points, the entity managing the data at that point is a CA in the RPKI, although some publication points are managed by end entities • At each publication point there will be a set of files, containing certificates, CRLs, ROAs, etc.

4. Publication Point Example 1 CAX CAY CAZ

5. Publication Point Example 2 < CAY Certificate> <CAX CRL> < CAX manifest> CAX Publication Point < CAY manifest> <CAY CRL-1> <CAY CRL-2> < EEY.1 Certificate> … < EEY.n Certificate> < EEY.1 ROA> … < EEY.n ROA> CAY Publication Point

6. Manifests and Certificates • A manifest is verified using an EE certificate issued under the CA that is the authority for the publication point for the manifest • For an EE-managed publication point, the manifest is verified using an EE certificate issued by the immediately superior CA

7. Manifest EE Certificate • The EE certificate used to verify the manifest • is carried in the CMS SignedData structure encapsulating the manifest; it is not published separately • uses the “inherit” flag in the RFC 3779 extension to reflect the resources inherited from the CA • If the publication point is associated with a CA, the CA certificate contains a persistent URI for the manifest • If the publication point is associated with a EE, that EE certificate contains a persistent URI for the manifest

8. Manifest Format • A manifest is a CMS SignedData payload: Manifest ::= SEQUENCE { version [0] INTEGER DEFAULT 0, manifestNumber INTEGER, thisUpdate GeneralizedTime, nextUpdate GeneralizedTime, fileHashAlg OBJECT IDENTIFIER, fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash} FileAndHash ::= SEQUENCE { file IA5String hash BIT STRING}

9. Manifest Data Elements • manifestNumber: a serial number used to help a relying party detect gaps • thisUpdate: the time/date at which this manifest was issued • nextUpdate: the time/date at which the next manifest will be issued • fileHashAlg: the one-way hash algorithm used to characterize the file contents • fileList: a list of file names and hashes

10. CMS Wrapper • A manifest is the payload of a CMS SignedData object • The CMS wrapper carries the EE certificate needed to verify the manifest signature • No CA certificates nor CRLS SHOULD be included in the CMS SignedData

11. Manifest & Certificate Lifetimes • There are two models for managing the EE certificate used to verify a manifest • Single-use: the certificate has the same validity interval as the manifest, so the private key for the certificate is destroyed after the manifest is signed • Persistent: the certificate has a validity interval that covers several manifests • If a manifest is issued prior to the next scheduled issue time, and a single-use EE certificate is employed, that EE certificate is revoked and a new EE certificate issued for the new manifest

12. Manifest Verification Criteria • The manifest syntax is valid • The signature is verified using the public key in the attached EE certificate • The current time is no earlier than the thisUpdate time of the manifest and no later than the nextUpdate time of the manifest • The EE certificate conforms to the profile as specified in [ID.SIDR-CERTPROFILE] • The EE certificate used to verify the manifest signature is valid (not revoked nor expired)

13. The Best Case • A manifest is present at a publication point • It is current (i.e., the current time is bounded by the manifest validity interval) • Its signature can be verified using the EE certificate in the CMS wrapper and that certificate can be validated • All files found in the publication point are listed in the manifest, all files listed in the manifest are found in the publication point, and the hashes match

14. Manifest OK, but File Problems Exist • If there are any files present at the publication point that are NOT listed in the manifest, ignore them and generate a warning • If there any files for which the hash value does not match, ignore them and generate a warning • If any listed files are missing, generate a warning, but use the extant, matching files

15. Manifest Signature is OK, but … • If the EE certificate is expired, use the files (subject to the rules on the previous slide) but generate a warning • If the EE certificate is revoked, ignore the manifest, generate a warning, and proceed as though the manifest was not present (see next slide)

16. Missing Manifest • If no manifest is found for a publication point • If a prior manifest is available for the publication point, use it and generate a warning • If no prior manifest is available for the publication point, just accept and process the files at the publication point, and generate a warning

17. Cannot Verify Manifest Signature • If a prior manifest is available for the publication point, use it and generate a warning • If no prior manifest is available for the publication point, just accept and process the files at the publication point, and generate a warning

18. Manifest Present but Expired • If the EE certificate is valid (current and not revoked), generate a warning and proceed • If the EE certificate is expired, then generate a warning and proceed • If the EE certificate is revoked but not expired, the manifest SHOULD be ignored. Generate a warning and proceed with processing as if no manifest is available (since the CA explicitly revoked the certificate for the manifest)

19. Q U E S T I O N S ? Questions?