On Tue, 19 Jul 2011, Terry Manderson wrote:
On 20/07/11 6:43 AM, "Randy Bush" <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
