draft-ietf-sidrops-6486bis-00.txt   draft-ietf-sidrops-6486bis-01.txt 
Network Working Group R. Austein Network Working Group R. Austein
Internet-Draft Arrcus, Inc. Internet-Draft Arrcus, Inc.
Updates: 6486 (if approved) G. Huston Updates: 6486 (if approved) G. Huston
Intended status: Standards Track APNIC Intended status: Standards Track APNIC
Expires: February 12, 2021 S. Kent Expires: May 3, 2021 S. Kent
Independent Independent
M. Lepinski M. Lepinski
New College Florida New College Florida
August 11, 2020 October 30, 2020
Manifests for the Resource Public Key Infrastructure (RPKI) Manifests for the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidrops-6486bis-00 draft-ietf-sidrops-6486bis-01
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,
Certificate Revocation List (CRL), or other type of signed objects Certificate Revocation List (CRL), or other type of signed objects
issued by the authority that are published at this repository issued by the authority that are published at this repository
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 12, 2021. This Internet-Draft will expire on May 3, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12 6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12
6.6. Out of Scope Manifest Entries . . . . . . . . . . . . . . 12 6.6. Out of Scope Manifest Entries . . . . . . . . . . . . . . 12
6.7. Failed Fetches . . . . . . . . . . . . . . . . . . . . . 12 6.7. Failed Fetches . . . . . . . . . . . . . . . . . . . . . 12
7. Publication Repositories . . . . . . . . . . . . . . . . . . 13 7. Publication Repositories . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of
a distributed repository system [RFC6481] to make available a variety a distributed repository system [RFC6481] to make available a variety
of objects needed by relying parties (RPs). Because all of the of objects needed by relying parties (RPs). Because all of the
objects stored in the repository system are digitally signed by the objects stored in the repository system are digitally signed by the
entities that created them, attacks that modify these published entities that created them, attacks that modify these published
objects are detectable by RPs. However, digital signatures provide objects are detectable by RPs. However, digital signatures provide
no protection against attacks that substitute "stale" versions of no protection against attacks that substitute "stale" versions of
skipping to change at page 12, line 8 skipping to change at page 12, line 8
this interval, proceed to Section 6.4. If the current time is this interval, proceed to Section 6.4. If the current time is
earlier than thisUpdate, the CA has made an error; this is a failed earlier than thisUpdate, the CA has made an error; this is a failed
fetch and the RP MUST proceed to Section 6.7. If the current time is fetch and the RP MUST proceed to Section 6.7. If the current time is
later than nextUpdate, then the manifest is stale; this is a failed later than nextUpdate, then the manifest is stale; this is a failed
fetch and RP MUST proceed to Section 6.7; otherwise proceed to fetch and RP MUST proceed to Section 6.7; otherwise proceed to
Section 6.4. Section 6.4.
6.4. Acquiring Files Referenced by a Manifest 6.4. Acquiring Files Referenced by a Manifest
The RP MUST acquire all of the files enumerated in the manifest The RP MUST acquire all of the files enumerated in the manifest
(fileList) from the publication point. This includes the CRL, each (fileList) from the publication point. If there are files listed in
object containing an EE certificate issued by the CA, and any the manifest that cannot be retrieved from the publication point, or
subordinate CA and EE certificates. If there are files listed in the if they fail the validity tests specified in [RFC6488], the fetch has
manifest that cannot be retrieved from the publication point, or if
they fail the validity tests specified in [RFC6488], the fetch has
failed and the RP MUST proceed to Section 6.7; otherwise, proceed to failed and the RP MUST proceed to Section 6.7; otherwise, proceed to
Section 6.5. Section 6.5. Note that all RPs MUST be able to process Manifests,
CRLs and Resource Certificates [RFC6487], BGPsec Router Certificates
[RFC8209], Ghostbuster Records [RFC6493], and ROAs [RFC6482]. The
set of retrieved objects may include other RPKI object types that the
RP is not prepared to process. When such objects are encountered by
an RP, the RP MUST NOT attempt to validate the eContent (as described
in Section 2.1.3.2 of [RFC8488]) of such objects; encountering such
objects does not, per se, result in a failed fetch.
6.5. Matching File Names and Hashes 6.5. Matching File Names and Hashes
The RP MUST verify that the hash value of each file listed in the The RP MUST verify that the hash value of each file listed in the
manifest matches the value obtained by hashing the file acquired from manifest matches the value obtained by hashing the file acquired from
the publication point. If the computed hash value of a file listed the publication point. If the computed hash value of a file listed
on the manifest does not match the hash value contained in the on the manifest does not match the hash value contained in the
manifest, then the fetch has failed and the RP MUST proceed to manifest, then the fetch has failed and the RP MUST proceed to
Section 6.7; otherwise proceed to Section 6.6. Section 6.7; otherwise proceed to Section 6.6.
6.6. Out of Scope Manifest Entries 6.6. Out of Scope Manifest Entries
If a current manifest contains entries for objects that are not If a current manifest contains entries for objects that are not
within the scope of the manifest (Section 6.2), the fetch has failed within the scope of the manifest (Section 6.2), the fetch has failed
and the RP SHOULD proceed to Section 6.7; otherwise the fetch is and the RP SHOULD proceed to Section 6.7; otherwise the fetch is
deemed successful and the RP will process the fetched objects. deemed successful and the RP will process the fetched objects.
6.7. Failed Fetches 6.7. Failed Fetches
If an RP does not acquire a current valid manifest, or does not If a fetch fails for any of the reasons cited in
acquire current valid instances of all of the objects enumerated in a Section 6.2-Section 6.6, the RP MUST issue a warning indicating the
current valid manifest as a result of a fetch, then processing of the reason(s) for termination of processing with regard to this CA
signed objects associated with the CA instance has failed for this instance. It is RECOMMENDED that a human operator be notified of
fetch cycle. The RP MUST issue a warning indicating the reason(s) this warning.
for termination of processing with regard to this CA instance. It is
RECOMMENDED that a human operator be notified of this warning.
Termination of processing means that the RP SHOULD continue to use Termination of processing means that the RP SHOULD continue to use
cached versions of the objects associated with this CA instance, cached versions of the objects associated with this CA instance,
until such time as they become stale or they can be replaced by until such time as they become stale or they can be replaced by
objects from a successful fetch. This implies that the RP MUST not objects from a successful fetch.This implies that the RP MUST not try
try to acquire and validate subordinate signed objects, e.g., to acquire and validate subordinate signed objects, e.g., subordinate
subordinate CA certificates, until the next interval when the RP is CA certificates, until the next interval when the RP is scheduled to
scheduled to fetch and process data for this CA instance. fetch and process data for this CA instance.
7. Publication Repositories 7. Publication Repositories
The RPKI publication system model requires that every publication The RPKI publication system model requires that every publication
point be associated with one or more CAs, and be non-empty. Upon point be associated with one or more CAs, and be non-empty. Upon
creation of the publication point associated with a CA, the CA MUST creation of the publication point associated with a CA, the CA MUST
create and publish a manifest as well as a CRL. A CA's manifest will create and publish a manifest as well as a CRL. A CA's manifest will
always contain at least one entry, namely, the CRL issued by the CA always contain at least one entry, namely, the CRL issued by the CA
upon repository creation [RFC6481]. upon repository creation [RFC6481].
skipping to change at page 14, line 35 skipping to change at page 14, line 35
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012, DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>. <https://www.rfc-editor.org/info/rfc6481>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for [RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
Use in the Resource Public Key Infrastructure (RPKI)", Use in the Resource Public Key Infrastructure (RPKI)",
RFC 6485, DOI 10.17487/RFC6485, February 2012, RFC 6485, DOI 10.17487/RFC6485, February 2012,
<https://www.rfc-editor.org/info/rfc6485>. <https://www.rfc-editor.org/info/rfc6485>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012, DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>. <https://www.rfc-editor.org/info/rfc6487>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>. <https://www.rfc-editor.org/info/rfc6488>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209,
DOI 10.17487/RFC8209, September 2017,
<https://www.rfc-editor.org/info/rfc8209>.
[RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's
Implementation of Resource Public Key Infrastructure
(RPKI) Certificate Tree Validation", RFC 8488,
DOI 10.17487/RFC8488, December 2018,
<https://www.rfc-editor.org/info/rfc8488>.
[X.690] International International Telephone and Telegraph [X.690] International International Telephone and Telegraph
Consultative Committee, "ASN.1 encoding rules: Consultative Committee, "ASN.1 encoding rules:
Specification of basic encoding Rules (BER), Canonical Specification of basic encoding Rules (BER), Canonical
encoding rules (CER) and Distinguished encoding rules encoding rules (CER) and Distinguished encoding rules
(DER)", CCITT Recommendation X.690, July 2002. (DER)", CCITT Recommendation X.690, July 2002.
11.2. Informative References 11.2. Informative References
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
 End of changes. 12 change blocks. 
23 lines changed or deleted 47 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/