RPKI Certificate PolicyStatus Update

Stephen Kent

2

Change Process We provided the MS Word master copy to Andrei

Robachevsky (RIPE), who coordinated changes with all the RIRs and returned the “change-tracked” version to us

Changes fall into a few categories Changed terminology globally (see next slide) Removed references to routing security Referred to CPS for more topics Better alignment with RIR policies Removed references to trust anchors, LIRs, NRO Algorithm specifications

The the document did not become shorter

3

Changes to Terminology/Definitions

“allocate” and “assign” “distribute” IP address(es) and AS number(s) Internet Number

Resource(s) (INR) “subscriber” “network subscriber” “uploading to” repositories “publishing via”

repositories “certificate holder” “subscriber” Defined INR Defined RPKI signed objects

4

Briefer, More General Text Removed description of RPKI infrastructure Removed references to specific uses of the RPKI,

e.g., routing security, resource transfers Changed text about ROAs to be about RPKI

signed objects Replaced details of applying for a certificate

(4.1.1) with pointer to CPS Replaced some of the details of circumstances for

revocation (4.9.1) with pointer to CPS Replaced some of the details for CA/RA

termination (5.8) with pointer to CPS

5

Alignment with RIR Ops/Policies

Removed mention of RIRs as trust anchors Removed mention of LIRs Deleted the expansion/definition of RIR

names Deleted definition of NRO (1.7) Changed CP approval procedures to be

made by the organizations administering the CP

6

Other Changes (1/2) 2.4. Access controls on repositories -- "Each CA shall

implement access controls to prevent unauthorized persons from adding, modifying or deleting repository entries. A CA shall not intentionally use technical means of limiting read access to its CPS, certificates, CRLs or RPKI signed objects”

4.5.2 Relying party public key and certificate usage -- reworked section to provide more detail on the responsibilities of the relying party

4.6.1 Circumstance for certificate renewal -- clarified that "Prior to the expiration of an existing subscriber's certificate, it is the responsibility of the subscriber to renew the certificate to maintain continuity of certificate usage.”

7

Other Changes (2/2) 5.6. Key changeover -- Focused on requirement to acquire

new certificate well before scheduled change of the current key pair. Deleted details re: validity period vs contractual period

6.1.3. Public key delivery to certificate issuer -- When a public key is transferred to the issuing CA to be certified, it shall be delivered through a mechanism ensuring that the public key has not been altered during transit and that the subscriber possesses the private key corresponding to the transferred public key.

6.1.5. Key sizes -- rewritten to specify algorithm/hash, need to accommodate transition to a different algorithm/hash, and key sizes.

8

Remaining Issues 1.6.4. CP approval procedures -- Should there be mention

of where the CP and amendments can be found? 3.2.4. Non-verified subscriber information – “No non-

verified subscriber data is included in certificates issued under this certificate policy.” but what about SIA? 

4.9.2. Who can request revocation -- "The subscriber or issuer may request a revocation.” Should there be reference to regional policies and CPS/business agreements (SSA)?

6.1.4. CA public key delivery to relying parties -- "The relying parties need to know who the TAs are and how are.

6.1.5. Key sizes -- Where should algorithm specs reside – certificate profile, CP, or a third document?

9

Questions?