Folks,
We just submitted a revised version of the following I-D:
Certificate Policy (CP) for the Resource PKI (RPKI)
draft-ietf-sidr-cp-04.txt
Thanks go to Geoff Huston, Randy Bush, and Tim Christensen for their
feedback. The main changes from the 03 version are listed below (not
including date changes, typo corrections and various minor wording
changes). Note that many of them but NOT all were in the non-IETF
version distributed to the rescert mailing list in May. Apologies in
advance if I missed any significant changes.
Looking forward to receiving your feedback (and completing this document :-)).
Karen
a. Corrected definition of a "bogus" route to include unauthorized
advertisement of an unallocated address (not just one that has been
allocated)
b. Changed text throughout the draft to allow the possibility of
additional as-yet-unagreed-upon signed objects (as opposed to just
ROAs).
c. Changed text throughout the draft from "distributing" PKI data to
"publishing PKI data in/into/at the RPKI distributed repository
system" (or similar text).
d. Added text throughout the draft to allow the possibility of other
routing-related uses of the RPKI data besides route filters.
e. 1.3.1 Certification authorities -- Added IANA and rewrote this in
attempt to clarify. It now says:
The organizations that allocate IP addresses (IANA, RIRs, NIRs,
LIRs/ISPs) and AS numbers (IANA, RIRs and NIRs) act as CAs in this
PKI.
Organizations that hold address space and create and sign objects
such as ROAs and manifests also act as CAs in this PKI. Such
organizations will include internet number registries, LIRs/ISPs,
provider-independent subscribers and some dual-homed subscribers.
For each signed object an organization creates, it will issue a
corresponding EE certificate that will be used to validate the
digital signature on the signed object. (Organizations may issue
other types of EE certificates in the future). See [ARCH] for more
details.
f. 1.3.5 Other Participants -- Now says:
Every organization that undertakes a role as a CA in this PKI is
responsible for populating the RPKI distributed repository system
with the certificates, CRLs, and other signed objects that it
issues. The organization can operate its own publication point or
outsource this function (See sections 2.1 and 2.2.)
g. 1.5.1 Organization administering the document -- Now says:
This CP is co-administered by IANA and the five Regional Internet
Registries (RIRs), which act as default trust anchors for the PKI:
and lists them with their addresses.
h. 1.5.2 Contact person -- Now lists general contact info for IANA
and the five RIRs.
i. The registries (IANA and the 5 RIRs) are now listed in alphabetic
order wherever they appear.
j. 3.1.1 Types of names -- Addition of IANA whose name will be a
"directory distinguished" name. Addition of NIRs to list of
organizations whose names "consist of a single CN attribute with a
value generated by the issuer."
k. 5.6 Key changeover -- Changed text to indicate that "Ideally, the
private key that a CA uses to sign a certificate or CRL should have a
validity period that is at least as long as that of any certificate
being signed. However, since a certificate issued under this PKI
will have a validity period that reflects the contractual
relationship between the issuer and subject, this may lead to
situations where an issued certificate has a validity period longer
than that of the key used to sign the certificate."
l. 5.8 CA or RA termination -- Changed text to indicate that "If an
organization acting as a CA in this PKI terminates operation without
identifying a replacement, then the effective control of the IP
addresses and AS numbers revert back to the issuing organization, and
address space and AS number allocations that have been previously
validated via that CA are invalidated as of revocation of the CA's
certificate."
m. 6.1.4 CA public key delivery to relying parties -- Added IANA to
list of entities whose public keys are distributed out of band, i.e.,
trust anchors. Deleted (RIRs) from the sentence that says "Public key
values and associated data for the default trust anchors will be
distributed out of band..."
n. 6.3.2 Certificate operational periods and key pair usage periods
-- Updated as follows to say:
IANA holds all IP address and AS number space, i.e., all the
resources which form the base of the RPKI hierarchy, Because a self-
signed IANA certificate represents this base, it should have a very
long life time.
Because RIRs and NIRs receive periodic new allocations, it is
appropriate for their key pairs and certificates to have lifetimes
that match the periodicity of these allocations. However, to
minimize disruption, the key pairs should be maintained across
certificate changes.
LIR/ISP and subscriber certificates typically will have validity
periods commensurate with the duration of service agreements. The
validity periods will be chosen by the issuing CA and described in
its CPS.
o. 9. Other Business and Legal Matters - Changed almost all
subsections to be "[OMITTED]" because there is no single set of
responses that would cover every relevant organization in the RPKI,
i.e., each of these organizations will have to specify this
information in its CPS or other document.
p. 9.12 Amendments -- Changed as follows -- NOTE that this needs to
be changed to match Secton 1.5.1. My apologies, I missed this.
9.12.1. Procedure for amendment
The procedure for amendments to this CP is via written notice from
the Secretary of the NRO.
9.12.2. Notification mechanism and period
The NRO will provide one month's notice of a change to this CP.
9.12.3. Circumstances under which OID must be changed [OMITTED]
If the Secretary judges that the change(s) will not materially
reduce the acceptability of certificates for RPKI purposes, then
there will be no change to the CP OID. If the Secretary judges that
the change(s) will materially change the acceptability of
certificates for RPKI purposes, then there will be a new CP OID.
q. References -- Added:
[REPOS] Huston, G., Loomans, R., and Michaelson, G., A Profile for
Resource Certificate Repository Structure, draft-huston-sidr-
repos-struct-01.txt, work in progress.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
