Re: [sidr] draft-ietf-sidr-repos-struct to Standards Track

On Tue, 19 Jul 2011, Terry Manderson wrote:

> On 20/07/11 6:43 AM, "Randy Bush" <randy@psg.com> wrote:
>
>>> ok. So in which case before I give in to making repos-struct a PS, I would
>>> want to see words somewhere that say that the validation choice for an RPKI
>>> object file is to based on the filename in the manifest and not on the
>>> transferred filename.
>>
>> again, the manifest may represent a proper subset of the valid objects in the
>> directory
>>
>
> Which I think is sloppy behaviour.

It is a fundamental part of the proposed repository structure.

The following text from section 2.2 of the repos-struct draft:

    The RPKI design requires that a CA be uniquely associated with a
    single key pair.  Thus, the administrative entity that is a CA
    performs key rollover by generating a new CA certificate with a new
    Subject name, as well as a new key pair [I-D.ietf-sidr-keyroll].
    (The reason for the new Subject name is that in the context of the
    RPKI the Subject names in all certificates issued by a CA are
    intended to be unique, and because the RPKI key rollover procedure
    creates a new instance of a CA with the new key, the name constraint
    implies the need for a new Subject name for the CA with the new key.)
    In such cases the entity SHOULD continue to use the same repository
    publication point for both CA instances during the key rollover,
    ensuring that the value of the AIA extension in indirect subordinate
    objects that refer to the certificates issued by this CA remain valid
    across the key rollover, and that the re-issuance of subordinate
    certificates in a key rollover is limited to the collection of
    immediate subordinate products of this CA.  In such cases the
    repository publication point will contain the CRL, manifest and
    subordinate certificates of both CA instances.

says that in times of CA key rollover, the publication point directory 
should contain two manifests and all the files from both manifests.  So 
neither manifest contains all the files names in the directory.

--Sandy, speaking as wg chair

>
> T.
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>