Re: [Sidrops] proposed, revised text for Section 6

[Oleg Muravskiy <[e-mail]>]

Hi Steve,

I have some comments inline:

> On 4 May 2020, at 22:08, Stephen Kent <stkent=[e-mail]> wrote:
> 
> 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).

Without additional context (the discussion we've had here on the list), it would not be clear for the reader where the possible multiple candidates for the “current”  manifest come from. The CA certificate contains a link (rsync URL) to a manifest, which is only one file, so how could there be multiple options to “select” from? I guess you refer to a possible use of a cache, or a difference between contents of rsync and RRDP repositories?

>  
>       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.

Wouldn’t we miss all the subordinate Resource Certificates if we only look at objects containing an EE certificate?
I think it would be enough if we say

	Acquire from this publication point all files listed in a manifest and verify that they are issued by this CA instance.

Although it would be better to expand the “verify” part.

Also, we should probably mention explicitly what the “publication point” is (see my later remark about possible discrepancy between different URLs from the CA cert).

>  
>  
>    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. 

The end of last sentence should have some duplicate words removed.

>  
> 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,

This should probably be the “the current, valid manifest”, not “any” (as we only consider one manifest as the current in 6.1/1)?

>    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.
> 


I wonder how far we should get with listing all possible inconsistencies in this document, but from my developer’s perspective I think  we should list as much as possible, if we want RP software to behave in the same way.

Going through what we described in RFC8488, one of such inconsistencies is when manifest contains more than one CRL entry.

Another is when the manifest is not in the publication point of a CA certificate. There are two distinct links from the CA certificate – one to the publication point, and one to the manifest. Technically, the manifest link could contain different directory than a publication point link. If you discover a manifest by following the manifest link, and follow the rules applied above, using the link from the CA cert (and not the location of the manifest), you would not catch this discrepancy.
Also note  that similar discrepancy could exist with the CRL location (as it also has its own link from the cert), but that one is covered by the new text above.

Cheers,
Oleg