[sidr] Certificate Policy for the RPKI -- new draft submitted

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.