RPKI Certificate Policy Status Update Stephen Kent.

Slides:



Advertisements
Similar presentations
A Profile for Trust Anchor Material for the Resource Certificate PKI Geoff Huston SIDR WG IETF 74.
Advertisements

Local TA Management A TA is a public key and associated data used as the starting point for certificate path validation It need not be a self-signed certificate.
RPKI Certificate Policy Status Update Stephen Kent.
RPKI Certificate Policy Stephen Kent, Derrick Kong, Ronald Watro, Karen Seo July 21, 2010.
An Introduction to Routing Security (and RPKI Tools) Geoff Huston May 2013.
Resource Certificate Profile Geoff Huston, George Michaelson, Rob Loomans APNIC IETF 67.
Validation Algorithms for a Secure Internet Routing PKI David Montana Mark Reynolds BBN Technologies.
CSCE 715: Network Systems Security Chin-Tser Huang University of South Carolina.
RPKI Validation - Revisited draft-huston-rpki-validation-01.txt Geoff Huston George Michaelson APNIC Slide 1/19.
Geneva, Switzerland, 2 June 2014 Introduction to public-key infrastructure (PKI) Erik Andersen, Q.11 Rapporteur, ITU-T Study Group 17 ITU Workshop.
Review of draft-ietf-sidr-arch-01.txt Steve Kent BBN Technologies.
Identity Standards (Federal Bridge Certification Authority – Certificate Lifecycle) Oct,
Resource PKI: Certificate Policy & Certification Practice Statement Dr. Stephen Kent Chief Scientist - Information Security.
1 REUNA Certificate Authority Juan Carlos Martínez REUNA Chile Rio de Janeiro,27/03/2006, F2F meeting, TAGPMA.
APNIC Trial of Certification of IP Addresses and ASes RIPE 52 Plenary George Michaelson Geoff Huston.
Resource Certificate Profile SIDR WG Meeting IETF 66, July 2006 draft-ietf-sidr-res-certs-01 Geoff Huston Rob Loomans George Michaelson.
The Resource Public Key Infrastructure Geoff Huston APNIC.
14 May 2002© TrueTrust Ltd1 Privilege Management in X.509(2000) David W Chadwick BSc PhD.
A PKI for IP Address Space and AS Numbers Stephen Kent.
APNIC eLearning: Intro to RPKI 10 December :30 PM AEST Brisbane (UTC+10)
+1 (801) Standards for Registration Practices Statements IGTF Considerations.
Certificate-Based Operations. Module Objectives By the end of this module participants will be able to: Define how cryptography is used to secure information.
March 27, 2006TAGPMA - Rio de Janeiro1 Short Lived Credential Services Profile Tony J. Genovese The Americas Grid PMA DOEGridsATF/ESnet/LBNL.
National Institute of Advanced Industrial Science and Technology Brief status report of AIST GRID CA APGridPMA Singapore September 16 Yoshio.
Draft Policy Standardize IP Reassignment Registration Requirements ARIN XXVI 6 October, 2010 – Atlanta, Georgia Chris Grundemann.
A Brief Overview of draft-ietf-sidr-cp-01.txt draft-ietf-sidr-cps-rirs-01.txt draft-ietf-sidr-cps-isp-00.txt Steve Kent BBN Technologies.
Public Key Infrastructure (X509 PKI) Presented by : Ali Fanian
© 2003 The MITRE Corporation. All rights reserved For Internal MITRE Use Addressing ISO-RTO e-MARC Concerns: Clarifications and Ramifications Response.
Who’s watching your network The Certificate Authority In a Public Key Infrastructure, the CA component is responsible for issuing certificates. A certificate.
Updates to the RPKI Certificate Policy I-D Steve Kent BBN Technologies.
“Trust me …” Policy and Practices in PKI David L. Wasley Fall 2006 PKI Workshop.
1 APNIC Trial of Certification of IP Addresses and ASes RIPE October 2005 Geoff Huston.
Status Report SIDR and Origination Validation Geoff Huston SIDR WG, IETF 71 March 2008.
Draft-ietf-sidr-roa-format draft-ietf-sidr-arch Matt Lepinski BBN Technologies.
Comments on draft-ietf-pkix-rfc3280bis-01.txt IETF PKIX Meeting Paris - August 2005 Denis Pinkas
RPKI Certificate Policy Status Update Stephen Kent.
HellasGrid CA self Audit. In general We do operations well Our policy documents need work (mostly to make the text clearer in a few sections) 2.
Key Rollover for the RPKI Steve Kent (Channeling Geoff Huston )
PRACE user authentication and vetting Vincent RIBAILLIER, 29 th EUGridPMA meeting, Bucharest, September 9 th, 2013.
TAG Presentation 18th May 2004 Paul Butler
Alternative Governance Models for PKI
Trusted? 05/4/2016 Charles Sheehe, CCSDS Security Working Group GRC POC All information covered is from public sources.
Public Key Infrastructure (PKI)
November 2006 Geoff Huston APNIC
Trust Anchor Management Problem Statement
Authority Recognition GGF9
Cryptography and Network Security
TAG Presentation 18th May 2004 Paul Butler
Authentication Applications
Voucher and Voucher Revocation Profiles for Bootstrapping Protocols draft-kwatsen-netconf-voucher-00 NETCONF WG IETF 97 (Seoul)
RPKI Trust Anchor Geoff Huston APNIC.
Chris Wendt, David Hancock (Comcast)
APNIC Trial of Certification of IP Addresses and ASes
Verstat Related Best Practices
Draft ETSI TS Annex C Presented by Michał Tabor for PSD2 Workshop
Transmitted by the expert
APNIC Trial of Certification of IP Addresses and ASes
Recommended Draft Policy ARIN : Post-IPv4-Free-Pool-Depletion Transfer Policy Staff Introduction.
RFC PASSporT Construction 6.2 Verifier Behavior
جايگاه گواهی ديجيتالی در ايران
Resource Certificate Profile
Digital Certificates and X.509
CS 465 Certificates Last Updated: Oct 14, 2017.
Based on the “Additional Guidelines” issued 3/30/2006
Progress Report on Resource Certification
ROA Content Proposal November 2006 Geoff Huston.
Resource Certificate Profile SIDR WG Meeting IETF 66, July 2006
WEQ-012 PKI Overview March 19, 2019
PKI (Public Key Infrastructure)
BPSec: AD Review Comments and Responses
Presentation transcript:

RPKI Certificate Policy Status Update Stephen Kent

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 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 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 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!

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 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 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 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 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.

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.

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.

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.”

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.

RPKI CPS Templates Status Update Stephen Kent

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.

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.”

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. ”

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]”

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.>”

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

Identification & authentication for revocation … “ … ”

Certificate application processing “ ”

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. ”

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. ”

Audit logging procedures “ ”

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, …>”

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. >”

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, … ”

& 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 9. Other Business And Legal Matters “ ”

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 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 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.

Comments & Questions?