draft-ietf-sidrops-rp-03.txt   draft-ietf-sidrops-rp-04.txt 
SIDROPS D. Ma SIDROPS D. Ma
Internet-Draft ZDNS Internet-Draft ZDNS
Intended status: Informational S. Kent Intended status: Informational S. Kent
Expires: August 1, 2019 Independent Expires: October 19, 2019 Independent
January 28, 2019 April 17, 2019
Requirements for Resource Public Key Infrastructure (RPKI) Relying Requirements for Resource Public Key Infrastructure (RPKI) Relying
Parties Parties
draft-ietf-sidrops-rp-03 draft-ietf-sidrops-rp-04
Abstract Abstract
This document provides a single reference point for requirements for This document provides a single reference point for requirements for
Relying Party (RP) software for use in the Resource Public Key Relying Party (RP) software for use in the Resource Public Key
Infrastructure (RPKI) in the context of securing Internet routing. Infrastructure (RPKI) in the context of securing Internet routing.
It cites requirements that appear in several RPKI RFCs, making it It cites requirements that appear in several RPKI RFCs, making it
easier for implementers to become aware of these requirements that easier for implementers to become aware of these requirements that
are segmented with orthogonal functionalities. are segmented with orthogonal functionalities.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 August 1, 2019. This Internet-Draft will expire on October 19, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 5, line 37 skipping to change at page 5, line 37
extensions mandated by Section 4.8 of [RFC6487] must be present and extensions mandated by Section 4.8 of [RFC6487] must be present and
value of each extension must be within the range specified by this value of each extension must be within the range specified by this
RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487] RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487]
must be omitted. must be omitted.
Section 7.1 of [RFC6487] gives the procedure that the RP should Section 7.1 of [RFC6487] gives the procedure that the RP should
follow to verify resource certificate and syntax. follow to verify resource certificate and syntax.
3.2. Certificate Path Validation 3.2. Certificate Path Validation
In the RPKI, issuer can only assign and/or allocate public INRs The INRs in issuer's certificate are required to encompass the INRs
belong to it, thus the INRs in issuer's certificate are required to in the subject's certificate. This is one of necessary principles of
encompass the INRs in the subject's certificate. This is one of certificate path validation in addition to cryptographic verification
necessary principles of certificate path validation in addition to i.e., verification of the signature on each certificate using the
cryptographic verification i.e., verification of the signature on public key of the parent certificate).
each certificate using the public key of the parent certificate).
Section 7.2 of [RFC6487] gives the procedure that the RP should Section 7.2 of [RFC6487] gives the procedure that the RP should
follow to perform certificate path validation. follow to perform certificate path validation.
Certificate Authorities that want to reduce aspects of operational Certificate Authorities that want to reduce aspects of operational
fragility will migrate to the new OIDs [RFC8360], informing the RP of fragility will migrate to the new OIDs [RFC8360], informing the RP of
using an alternative RPKI validation algorithm. An RP is expected to using an alternative RPKI validation algorithm. An RP is expected to
support the amended procedure to handle with accidental over-claim. support the amended procedure to handle with accidental over-claim.
3.3. CRL Processing 3.3. CRL Processing
The CRL processing requirements imposed on CAs and RP are described The CRL processing requirements imposed on CAs and RP are described
in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained; in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained;
only the AuthorityKeyIndetifier and CRLNumber extensions are allowed, only the AuthorityKeyIndetifier and CRLNumber extensions are allowed,
and they MUST be present. No other CRL extensions are allowed, and and they are required to be present. No other CRL extensions are
no CRLEntry extensions are permitted. RPs are required to verify allowed, and no CRLEntry extensions are permitted. RPs are required
that these constraints have been met. Each CRL in the RPKI MUST be to verify that these constraints have been met. Each CRL in the RPKI
verified using the public key from the certificate of the CA that must be verified using the public key from the certificate of the CA
issued the CRL. that issued the CRL.
In the RPKI, RPs are expected to pay extra attention when dealing In the RPKI, RPs are expected to pay extra attention when dealing
with a CRL that is not consistent with the Manifest associated with with a CRL that is not consistent with the Manifest associated with
the publication point associated with the CRL. the publication point associated with the CRL.
Processing of a CRL that is not consistent with a manifest is a Processing of a CRL that is not consistent with a manifest is a
matter of local policy, as described in the fourth paragraph of matter of local policy, as described in the fourth paragraph of
Section 6.6 of [RFC6486]. Section 6.6 of [RFC6486].
4. Processing RPKI Repository Signed Objects 4. Processing RPKI Repository Signed Objects
skipping to change at page 7, line 13 skipping to change at page 7, line 13
as though no manifest were present. as though no manifest were present.
4.2.2. ROA 4.2.2. ROA
To validate a ROA, the RP is required perform all the checks To validate a ROA, the RP is required perform all the checks
specified in [RFC6488] as well as the additional ROA-specific specified in [RFC6488] as well as the additional ROA-specific
validation steps. The IP address delegation extension [RFC3779] validation steps. The IP address delegation extension [RFC3779]
present in the end-entity (EE) certificate (contained within the present in the end-entity (EE) certificate (contained within the
ROA), must encompass each of the IP address prefix(es) in the ROA. ROA), must encompass each of the IP address prefix(es) in the ROA.
More details for ROA validation are specified in Section 2 of More details for ROA validation are specified in Section 4 of
[RFC6482]. [RFC6482].
4.2.3. Ghostbusters 4.2.3. Ghostbusters
The Ghostbusters Record is optional; a publication point in the RPKI The Ghostbusters Record is optional; a publication point in the RPKI
can have zero or more associated Ghostbuster Records. If a CA has at can have zero or more associated Ghostbuster Records. If a CA has at
least one Ghostbuster Record, RP is required to verify that this least one Ghostbuster Record, RP is required to verify that this
Ghostbusters Record conforms to the syntax of signed object defined Ghostbusters Record conforms to the syntax of signed object defined
in [RFC6488]. in [RFC6488].
skipping to change at page 8, line 10 skipping to change at page 8, line 10
For a given publication point, the RP ought to perform tests, as For a given publication point, the RP ought to perform tests, as
specified in Section 6.1 of [RFC6486], to determine the state of the specified in Section 6.1 of [RFC6486], to determine the state of the
Manifest at the publication point. A Manifest can be classified as Manifest at the publication point. A Manifest can be classified as
either valid or invalid, and a valid Manifest is either current and either valid or invalid, and a valid Manifest is either current and
stale. An RP decides how to make use of a Manifest based on its stale. An RP decides how to make use of a Manifest based on its
state, according to local (RP) policy. state, according to local (RP) policy.
If there are valid objects in a publication point that are not If there are valid objects in a publication point that are not
present on a Manifest, [RFC6486] does not mandate specific RP present on a Manifest, [RFC6486] does not mandate specific RP
behavior with respect to such objects. However, most RP software behavior with respect to such objects. However, most RP software
ignores such objects and this document recommends that this behavior ignores such objects and the authors of this document suggest this
be adopted uniformly. behavior be adopted uniformly.
In the absence of a Manifest, an RP is expected to accept all valid In the absence of a Manifest, an RP is expected to accept all valid
signed objects present in the publication point. If a Manifest is signed objects present in the publication point. If a Manifest is
stale or invalid (see [RFC6486]) and an RP has no way to acquire a stale or invalid (see [RFC6486]) and an RP has no way to acquire a
more recently valid Manifest, the RP is expected to contact the more recently valid Manifest, the RP is expected to contact the
repository manager via Ghostbusters record and thereafter make repository manager via Ghostbusters record and thereafter make
decision according to local (RP) policy. decision according to local (RP) policy.
4.4. What to Do with Ghostbusters Information 4.4. What to Do with Ghostbusters Information
skipping to change at page 9, line 11 skipping to change at page 9, line 11
should support application of secure transport (e.g., IPsec should support application of secure transport (e.g., IPsec
[RFC4301]) that is able to protect validated cache delivery in a [RFC4301]) that is able to protect validated cache delivery in a
unsafe environment. unsafe environment.
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Acknowledgements 8. Acknowledgements
The authors thank David Mandelberg, Wei Wang and Tim Bruijnzeels for The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George
their review, feedback and editorial assistance in preparing this Michaelson and Oleg Muravskiy for their review, feedback and
document. editorial assistance in preparing this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-sidrops-https-tal] [I-D.ietf-sidrops-https-tal]
Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", draft-ietf-sidrops-https-tal-06 Trust Anchor Locator", draft-ietf-sidrops-https-tal-07
(work in progress), January 2019. (work in progress), March 2019.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
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,
 End of changes. 9 change blocks. 
23 lines changed or deleted 22 lines changed or added

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