Manifests(and Destiny?)

Stephen KentBBN 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

CAX

CAY CAZ

Publication Point Example 2

< CAY manifest> <CAY CRL-1><CAY CRL-2>< EEY.1 Certificate>…< EEY.n Certificate>< EEY.1 ROA>…< EEY.n ROA>

CAY Publication Point

< CAY Certificate><CAX CRL>< CAX manifest>

CAX 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 ?