1. RPKI Certificate Policy Status Update Stephen Kent

2. 2 Certificate Policy – remaining items  Review use of “will”, “should,” “shall”, “may,” etc. for possible replacement with MUST/SHOULD/MAY  Address other feedback from Geoff Huston l Abstract and Introduction (paragraph 1); Overview1.1. l 1.4.1 Appropriate certificate uses l 2.2 Publication of certification information l 2.3 Time or frequency of publication l 3.2 vs 3.3 – combined or separate? l 3.4 Identification & authentication for revocation request l 4.5.2 Relying party public key and certificate usage l 4.8 Circumstance for certificate modification l 4.10 Certificate status services l 5.8 CA or RA termination

3. 3 Remove “unique” in several places  Abstract and Introduction: “These certificates will enable verification that the resources indicated in the certificate have been distributed to the holder of the associated private key and that this organization is the current, unique holder of these resources.”  1.1 Overview: “The ability to verify such claims is essential to ensuring the unique, unambiguous distribution of these resources. Geoff, you put “unique” here!

4. 4 1.4.1 Certification Authorities the document appear to preclude LIRs (ISPs) from distributing AS numbers, which is inappropriate and not accurate in today’s environment Yes, it does prohibit such behavior, as we were told that only RIRs and NIRs are legitimate distributors of AS #’s. (BTW, this limitation has appeared in the text and in briefings for at least 3 years )

5. 5 2.2 Publication of certification information  Is a CA responsible for publishing ALL certificates, CRLs, and RPKI-signed objects, or can it be selective in its publication? Certificates, CRLs, and other signed objects must be published to enable use by RPs, so what signed thingies would the CA not want to publish?

6. 6 2.3 Time or frequency of publication  the document does not specify a CA’s actions regarding publication of expired and revoked certificates, … CAs don’t generally publish certificates after they have expired. Revoked certificates are implicitly published on CRLs. RFC 5280 describes the only context in which an expired, revoked certificate MUST appear on a CRL. Only in a non-repudiation context might it make sense to maintain repository entries for such certificates, and the RPKI is not intended to support NR. So, we can add some text to state these typical PKI conventions for the RPKI context.

7. 7 3.2 vs 3.3 – combined or separate?  Do 3.2 and 3.3 need to be separate sections? There are some subtle differences in wording, consistent with the fact that initial certificate issuance is not exactly the same as rekey. So, unless we feel a really strong need to reduce page count …

8. 8 3.4 Identification & authentication for revocation request  – This section does not have the detail of 3.2. Should it refer to 3.2? Not all of the 3.2 subsections apply to a revocation request, e.g., PoP is not intrinsically needed, non-verified subscriber info is irrelevant, etc. Thus it seems reasonable to provide a truncated policy description here.

9. 9 4.5.2 Relying party public key and certificate usage  How does local TA management interact with the text: “…Before any act of reliance, relying parties shall independently 1)verify that the certificate will be used for an appropriate purpose that is not prohibited or otherwise restricted by this CP, and 2) assess the status of the certificate and all the CAs in the chain that issued the certificates relevant to the certificate in question….” Since every RP is empowered to select its own set of TAs, “the chain” is determined by each RP’s local choices. The RP is still responsible for checking the (revocation status) of each CA in the chain.

10. 10 4.8 Circumstance for certificate modification  Why is augmentation of a subject’s INR treated differently from a reduction? Adding resources does not require revocation of the “old” certificate, while reducing resources does.

11. 11 4.10 Certificate status services  Is it true to say that “This PKI does not make use of OCSP or SCVP” or is it more appropriate to say “Relying parties SHOULD NOT rely on the use of OCSP or SCVP?” The text is correct as it stands, but we can augment it, e.g., “This PKI does not make use of OCSP or SCVP. CAs in the RPKI issue CRLs and RPs MUST NOT rely upon any other means of acquiring revocation status information.”

12. 12 5.8 CA or RA termination  What is the rationale for the requirement of an agreement between issuer and subscriber. “…The termination of a CA shall therefore be subject to the agreement between the issuer and the subscriber and will be described in the CPS for the issuer.” A CA generally requires a formal agreement between itself and the entities to which it issues certificates. This text just says that what the CA will do if it terminates its services will be described in the CPS. But, given that subscribers here are also trivial CAs we need to provide a blanket exception for the case where the CA is a stub.

13. RPKI CPS Templates Status Update Stephen Kent

14. 14 CPS for Internet Registries & ISPs Changes to the CPS templates were made to align with changes made to the CP  Moved specifics from CP to CPS, often changing from specifying what should be done to leaving it to the Registry or ISP to define what was done  Made terminology and wording consistency changes throughout  Generalized how the RPKI can be used  Shortened the documents a little, abbreviating the background text, deleting “omitted” sections  Updated boilerplate, dates, etc.

15. 15 2.3 Time or Frequency of Publication  Added: “This SHOULD include the period of time within which a certificate will be published after the CA issues the certificate and the period of time within which a CA will publish a CRL with an entry for a revoked certificate after it revokes that certificate. As per the CP, the following standard exists for publication times and frequency: The RPKI CA MUST publish its CRL prior to the nextScheduledUpdate value in the scheduled CRL previously issued by the CA.”

16. 16 3.1.1 Types of Names  “The Subject of each certificate issued by this Registry is identified by an X.500 Distinguished Name (DN). The distinguished name MUST consist of a single Common Name (CN) attribute with a value generated by. Optionally, the serialNumber attribute MAY be included along with the common name (to form a terminal relative distinguished name set), to distinguish among successive instances of certificates associated with the same entity. ”

17. 17 3.2.1 Method to prove possession of private key “Describe the method whereby each subscriber will be required to demonstrate proof-of-possession (PoP) of the private key corresponding to the public key in the certificate, prior to issuing the certificate. One possible approach makes use of the PKCS #10 format, as profiled in [RFCyyyy]”

18. 18 3.2.3 Authentication of Individual Identity “ BPKI (see Section 3.2.6) issues certificates that MUST be used to identify individuals who represent subscribers.” The procedures should be commensurate with those you already employ in authenticating individuals as representatives for INR holders. Note that this authentication is solely for use by you in dealing with the organizations to which you distribute (or sub-distribute) INRs, and thus must not be relied upon outside of this CA-subscriber relationship.>”

19. 19 3.2.4 Non-verified subscriber info “No non-verified subscriber data is included in certificates issued under this certificate policy except for SIA/AIA extensions. ”

20. 20 3.4 Identification & authentication for revocation … “ … ”

21. 21 4.2 Certificate application processing “ ”

22. 22 4.4.1 Conduct constituting certificate acceptance “When a certificate is issued, the CA MUST publish it to the repository and notify the subscriber. This will be done without subscriber review and acceptance. ”

23. 23 4.4.2 Publication of the certificate by the CA “Certificates MUST be published in the RPKI distributed repository system via publication of the certificate at ’s repository publication. This will be done within. ”

24. 24 5.4 Audit logging procedures “ ”

25. 25 5.6 Key changeover “The CA certificate MUST contain a validity period that is at least as long as that of any certificate being issued under that certificate. When CA wishes to change keys, …>”

26. 26 6.1.3 Public key delivery to certificate issuer “ RPKI CA. These procedures should ensure that the public key has not been altered during transit and that the subscriber possesses the private key corresponding to the transferred public key. >”

27. 27 6.1.4 CA public key delivery to relying parties “CA public keys for all entities (other than trust anchors) are contained in certificates issued by other CAs and MUST be published via the RPKI repository system. Relying parties download these certificates from this system. Public key values and associated data for (putative) trust anchors is distributed out of band and accepted by relying parties on the basis of locally- defined criteria, … ”

28. 28 6.1.4 & 6.1.6 Key sizes & Params “The key sizes used in this PKI are as specified in RFC ZZZZ [RFCzzzz].” “The public key algorithms and parameters used in this PKI are as specified in RFC ZZZZ [RFCzzzz].”

29. 29 9. Other Business And Legal Matters “ ”

30. 30 Terminology and Consistency Changes  Internet IP Address and Autonomous System (AS) Number PKI  Resource PKI (RPKI)  Assign or allocate  distribute  AS#, IP address  Internet Number Resource (INR)  Resource holder, certificate holder, address holder, INR holder  subscriber  ROA or signed object  RPKI-signed object  Upload or post to repository  publish to repository  Removed usage of LIR; use only RIR, NIR, and ISP  Added definition of IANA plus above terms  Removed references to ROA or routing

31. 31 Shortened the Document Only slightly successful, saved just a few pages.  Tightened up the wording re: how the section numbering is the same as that in RFC 3647  Removed much of the background text that described the architecture and the original “routing” motivation (replaced with more general text that focuses on validation of INR holdings)  Deleted all section headers marked “OMITTED”

32. 32 What’s Left to Do  Review use of “will”, “should,” “shall”, “may,” etc. for possible replacement with MUST/SHOULD/MAY  Consider combining CPS for Internet Registries with CPS for ISPs into one document with text specific to each where needed.  Make sure CPSs track any changes made to the CP.  Delete a couple of “OMITTED” sections.

33. Comments & Questions?