Manifests (and Destiny?) Stephen Kent BBN Technologies

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.

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.

Publication Point Example 1 CA X CA Y CA Z

Publication Point Example 2 … … CA Y Publication Point CA X Publication Point

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

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

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}

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

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

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

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)

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

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

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)

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

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

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)

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