rfc9286v2.txt   rfc9286.txt 
Internet Engineering Task Force (IETF) R. Austein Internet Engineering Task Force (IETF) R. Austein
Request for Comments: 9286 Arrcus, Inc. Request for Comments: 9286 Arrcus, Inc.
Obsoletes: 6486 G. Huston Obsoletes: 6486 G. Huston
Category: Standards Track APNIC Category: Standards Track APNIC
ISSN: 2070-1721 S. Kent ISSN: 2070-1721 S. Kent
Independent Independent
M. Lepinski M. Lepinski
New College Florida New College Florida
May 2022 June 2022
Manifests for the Resource Public Key Infrastructure (RPKI) Manifests for the Resource Public Key Infrastructure (RPKI)
Abstract Abstract
This document defines a "manifest" for use in the Resource Public Key This document defines a "manifest" for use in the Resource Public Key
Infrastructure (RPKI). A manifest is a signed object (file) that Infrastructure (RPKI). A manifest is a signed object (file) that
contains a listing of all the signed objects (files) in the contains a listing of all the signed objects (files) in the
repository publication point (directory) associated with an authority repository publication point (directory) associated with an authority
responsible for publishing in the repository. For each certificate, responsible for publishing in the repository. For each certificate,
skipping to change at line 173 skipping to change at line 173
Where multiple CA instances share a common publication point, as can Where multiple CA instances share a common publication point, as can
occur when a CA performs a key-rollover operation [RFC6489], the occur when a CA performs a key-rollover operation [RFC6489], the
repository publication point will contain multiple manifests. In repository publication point will contain multiple manifests. In
this case, each manifest describes only the collection of published this case, each manifest describes only the collection of published
products of its associated CA instance. products of its associated CA instance.
3. Manifest Signing 3. Manifest Signing
A CA's manifest is verified using an EE certificate. The A CA's manifest is verified using an EE certificate. The
SubjectInfoAccess (SIA) field of this EE certificate contains the SubjectInfoAccess (SIA) field of this EE certificate contains the
access method Object Identifier (OID) of id-ad-signedObject. accessMethod Object Identifier (OID) of id-ad-signedObject.
The CA MUST sign only one manifest with each generated private key The CA MUST sign only one manifest with each generated private key
and MUST generate a new key pair for each new version of the and MUST generate a new key pair for each new version of the
manifest. An associated EE certificate used in this fashion is manifest. An associated EE certificate used in this fashion is
termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]). termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]).
4. Manifest Definition 4. Manifest Definition
A manifest is an RPKI signed object, as specified in [RFC6488]. The A manifest is an RPKI signed object, as specified in [RFC6488]. The
RPKI signed object template requires specification of the following RPKI signed object template requires specification of the following
skipping to change at line 311 skipping to change at line 311
4.2.2. Names in FileAndHash Objects 4.2.2. Names in FileAndHash Objects
Names that appear in the fileList MUST consist of one or more Names that appear in the fileList MUST consist of one or more
characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _
(UNDERSCORE), followed by a single . (DOT), followed by a three- (UNDERSCORE), followed by a single . (DOT), followed by a three-
letter extension. The extension MUST be one of those enumerated in letter extension. The extension MUST be one of those enumerated in
the "RPKI Repository Name Scheme" registry maintained by IANA the "RPKI Repository Name Scheme" registry maintained by IANA
[IANA-NAMING]. [IANA-NAMING].
As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid file name.
The example above contains a mix of uppercase and lowercase The example above contains a mix of uppercase and lowercase
characters in the filename. CAs and RPs MUST be able to perform characters in the file name. CAs and RPs MUST be able to perform
filesystem operations in a case-sensitive, case-preserving manner. filesystem operations in a case-sensitive, case-preserving manner.
4.3. Content-Type Attribute 4.3. Content-Type Attribute
The mandatory content-type attribute MUST have its attrValues field The mandatory content-type attribute MUST have its attrValues field
set to the same OID as eContentType. This OID is id-ct-rpkiManifest set to the same OID as eContentType. This OID is id-ct-rpkiManifest
and has the numerical value of 1.2.840.113549.1.9.16.1.26. and has the numerical value of 1.2.840.113549.1.9.16.1.26.
4.4. Manifest Validation 4.4. Manifest Validation
skipping to change at line 616 skipping to change at line 616
attacks against the manifest are detectable within the time frame of attacks against the manifest are detectable within the time frame of
the regular schedule of manifest updates. Forms of replay attacks the regular schedule of manifest updates. Forms of replay attacks
within finer-grained time frames are not necessarily detectable by within finer-grained time frames are not necessarily detectable by
the manifest structure. the manifest structure.
9. IANA Considerations 9. IANA Considerations
The "RPKI Signed Objects" registry was originally created and The "RPKI Signed Objects" registry was originally created and
populated by [RFC6488]. The "RPKI Repository Name Schemes" registry populated by [RFC6488]. The "RPKI Repository Name Schemes" registry
was created by [RFC6481] and created four of the initial three-letter was created by [RFC6481] and created four of the initial three-letter
filename extensions. IANA has updated the reference for the file name extensions. IANA has updated the reference for the
"Manifest" row in the "RPKI Signed Objects" registry to point to this "Manifest" row in the "RPKI Signed Objects" registry to point to this
document. document.
IANA has also updated the following entries to refer to this document IANA has also updated the following entries to refer to this document
instead of RFC 6486: instead of RFC 6486:
* id-mod-rpkiManifest (60) in the "SMI Security for S/MIME Module * id-mod-rpkiManifest (60) in the "SMI Security for S/MIME Module
Identifier (1.2.840.113549.1.9.16.0)" registry Identifier (1.2.840.113549.1.9.16.0)" registry
* id-ct-rpkiManifest (26) in the "SMI Security for S/MIME CMS * id-ct-rpkiManifest (26) in the "SMI Security for S/MIME CMS
skipping to change at line 786 skipping to change at line 786
validity period that coincides with the interval specified in the validity period that coincides with the interval specified in the
manifest eContent, which coincides with the CRL's thisUpdate and manifest eContent, which coincides with the CRL's thisUpdate and
nextUpdate. nextUpdate.
* Clarifying that the manifestNumber is monotonically incremented in * Clarifying that the manifestNumber is monotonically incremented in
steps of 1. steps of 1.
* Recommending that CA issuers include the applicable CRL's * Recommending that CA issuers include the applicable CRL's
nextUpdate with the manifest's nextUpdate. nextUpdate with the manifest's nextUpdate.
* Constraining the set of valid characters in FileAndHash filenames. * Constraining the set of valid characters in FileAndHash file
names.
* Clarifying that an RP unable to obtain the full set of files * Clarifying that an RP unable to obtain the full set of files
listed on a manifest is considered to be in a failure state, in listed on a manifest is considered to be in a failure state, in
which case cached data from a previous attempt should be used (if which case cached data from a previous attempt should be used (if
available). available).
* Clarifying the requirement for a current CRL to be present, * Clarifying the requirement for a current CRL to be present,
listed, and verified. listed, and verified.
* Removing the notion of "local policy". * Removing the notion of "local policy".
 End of changes. 6 change blocks. 
6 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

mirror server hosted at Truenetwork, Russian Federation.