[Sidrops] proposed, revised text for Section 6

[Stephen Kent <[e-mail]>]

To get the discussion going, I generated the following text for Section 
6. I deleted anything that was not definitive (e.g., deferred to local 
policy) and removed the warning message suggested text (I assume RP 
software developers can write their own messages, but we can add this 
back if folks feel it's useful.

I also added a paragraph about the manifest/CRL circular relationship.

In all cases I adopted the approach George suggested, i.e., if there's 
an error indicating that one or more signed objects may be missing (or 
not current), ignore ALL data associated with the CA instance at the pub 
point and DO NOT rely on cached data.

Comments welcome, as usual.

All new text is in red.

Steve

-----



6.1. Determining Manifest State & Object Acceptance

For a given publication point, and given CA instance, an RP MUST perform

the following tests to determine the manifest state of the publication

point. (Note that, during CA key rollover [RFC6489], signed objects for

two or more different CA instances will appear at the same publication

point. The tests described below are to be performed for a specified CA

instance, i.e., a the manifest’s EE certificate was issued by that CA.)

1. Select the CA's current manifest (the "current" manifest is the

manifest issued by this CA having the highest manifestNumber among

all valid manifests (as defined in Section 4.4).

If the publication point does not contain a valid manifest, proceed

as described in Section 6.2. (Lacking a valid manifest, the following

tests cannot be performed.)

2. Check that the current time (translated to UTC) is between

thisUpdate and nextUpdate.

If the current time does not lie within this interval,proceed

as described in Section 6.4.

3. Acquire all objects at the publication point associated with this

CA instance, i.e., the CRL and each object containing an EE

certificate issued by the CA. If there are files listed in a manifest

that do not appear at the publication point, then proceed as

described Section 6.5.

4. Verify that the listed hash value of every file listed in the

manifest matches the value obtained by hashing the file at the

publication point.

If the computed hash value of a file listed on the manifest does

not match the hash value contained in the manifest, then proceed

as described in Section 6.6.

5. If a current manifest contains entries for objects that are not

within the scope of the manifest, then the out-of-scope entries

MUST be disregarded in the context of this manifest.If there

is no other current manifest that describes these objects within

that other manifest's scope, then see Section 6.2.

Note that there is a “chicken and egg” relationship between the

manifest and the CRL for a given CA instance. If the EE certificate

for the manifest is revoked, the CA or publication point manager has

made an error. In this case all signed objects associated with the CA

instance MUST be ignored. Similarly, if the CRL for the CA instance

is not listed on a valid, current manifest, all signed objects

associated with the CA instance MUST be ignored, because the CRL is

missing.

6.2.Missing Manifests

The absence of a current manifest at a publication point could occur

due to an error by the publisher or due to (malicious or accidental)

deletion or corruption of all valid manifests.

When no valid manifest is available, there is no protection against

attacks that delete signed objects or replay old versions of signed

objects. To guard against the adverse impact of processing an

incomplete set of signed objects, an RP MUST treat all signed objects

associated with the missing manifest as invalid. (These objects are

all issued by the same instance of a CA.) RP software MUST issue a

warning when there is no current manifest for a CA instance.

An RP may have access to a local cache containing a previously

issued manifest that is still valid. It is RECOMMENDED that the RP

not make use of this data, to ensure consistent a consistent outcome

in when a manifest is missing.

6.3.Invalid Manifests

The presence of an invalid manifest at a publication point could

occur due to an error by the publisher or due to (malicious or

accidental) corruption of a valid manifest.An invalid manifest MUST

never be used, even if the manifestNumber of the invalid manifest is

greater than that of other (valid) manifests.

If there is no valid, current manifest available at the publication

point for the CA instance, an RP MUST treat the signed objects at the

publication point as indicated above in Section 6.2. A warning MUST

be issued when an invalid manifest is encountered.

6.4.Stale Manifests

A manifest is considered stale if the current time is after the

nextUpdate time for the manifest.This could be due to publisher

failure to promptly publish a new manifest, or due to (malicious or

accidental) corruption or suppression of a more recent manifest.

All signed objects at the publication point issued by the entity that

has published the stale manifest, and all descendant signed objects

that are validated using a certificate issued by the entity that has

published the stale manifest at this publication point, MUST be

treated at invalid and a warning MUST be issued.

The primary risk in using such signed objects is that a newer

manifest exists that, if present, would indicate that certain objects

have been removed or replaced.(For example, the new manifest might

show the existence of a newer CRL and the removal of one or more

revoked certificates).Thus, the use of objects from a stale

manifest may cause an RP to incorrectly treat invalid objects as

valid.The risk is that the CRL covered by the stale manifest has

been superseded, and thus an RP will improperly treat a revoked

certificate as valid.

6.5.Mismatch between Manifest and Publication Point

If there exist valid signed objects associated with a CA instance and

they do not appear in any current, valid manifest for this CA instance,

these objects MUST be ignored by an RP, and a warning MUST be issued.

If there are files listed on the manifest that do not appear in

the repository, then these objects have been improperly deleted from

repository (via malice or accident).A primary purpose of manifests is

to detect such deletions.Therefore, in this case, an RP MUST ignore

all signed objects associated with this CA instance.

6.6.Hash Values Not Matching Manifests

A file appearing on a manifest with an incorrect hash value could

occur because of publisher error, but it also may indicate that an

attack has occurred, e.g., one in which an older version of an object

has been substituted for a newer version of the object. In this case

an RP cannot know the content of the missing object, and thus all

signed objects associated with this instance of the CA MUST be ignored

by the RP, and a warning MUST be issued.