Re: [sidr] RPKI <-> allocation consistency

Stephen Kent <kent@bbn.com> Sat, 25 August 2012 09:19 UTC

Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D426721F84F9 for <sidr@ietfa.amsl.com>; Sat, 25 Aug 2012 02:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.523
X-Spam-Level:
X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I5gzi4mMqWF for <sidr@ietfa.amsl.com>; Sat, 25 Aug 2012 02:19:25 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB621F84F5 for <sidr@ietf.org>; Sat, 25 Aug 2012 02:19:24 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:55784 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1T5CWX-0008CD-2B; Sat, 25 Aug 2012 05:19:23 -0400
Message-ID: <50389897.3040503@bbn.com>
Date: Sat, 25 Aug 2012 05:19:19 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: sidr@ietf.org, eosterweil@verisign.com
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <D857A4BB-E484-45A4-A09F-FB8FAF2215AC@tcb.net> <C5B88834-3A10-41F7-A4F3-2B7C9B540197@verisign.com>
In-Reply-To: <C5B88834-3A10-41F7-A4F3-2B7C9B540197@verisign.com>
Content-Type: multipart/alternative; boundary="------------040805030004090302010106"
Subject: Re: [sidr] RPKI <-> allocation consistency
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Aug 2012 09:19:25 -0000

Eric,

The short answer to your question is that each CA is supposed to ensure 
that the certs it issues match its allocation database. This applies to 
both cert issuance and cert revocation. A quick look at the RPKI RFCs 
provides a few examples of statements about the RPKI consistency model.

Steve
-----

RFC 6487 (Certificate Profile)

Intro:

Resource certificates are to be used in a manner that is consistent

with the RPKI Certificate Policy (CP) [RFC6484].*They are issued by*

*entities that assign and/or allocate public INRs, and thus the RPKI*

*is aligned with the public INR distribution function.*

*The specific goal for the associated RPKI is to precisely match the INR*

*allocation structure through an aligned certificate structure*

*that describes the allocation and its context within the INR*

*distribution hierarchy.*

RFC 6484 (RPKI CP)

Overview

*This PKI is designed to support validation of claims by current*

*holders of INRs, in accordance with the records of the organizations*

*that act as Certification Authorities (CAs) in this PKI.*

**

Section 3.3.2.Identification and Authentication for Re-Key after Revocation

*Each CA operating within the context of this PKI MUST employ*

*procedures to ensure that each certificate it issues accurately*

*reflects its records with regard to the organization to which the CA*

*has distributed the INRs identified in the certificate.**The specific*

*procedures employed for this purpose MUST be described by the CPS for*

*each CA.*

Section 3.4.Identification and Authentication for Revocation Request

Each CA operating within the context of this PKI MUST employ

procedures to ensure that:

*oan organization requesting revocation is the legitimate holder of*

*the certificate to be revoked.*

o*each certificate it revokes accurately reflects its records with*

*regard to the organization to which the CA has distributed the*

*INRs identified in the certificate*.

Section 4.2.2.Approval or Rejection of Certificate Applications

*Certificate applications MUST be approved based on the normal*

*business practices of the entity operating the CA, based on the CA's*

*records of INR holders.*



> Indeed, I vaguely recall some conversations (on the list?) about the specific consistency model that the RPKI is trying to achieve.  I wasn't able to unearth the thread, but what was the conclusion?  That is, what is the consistency model that the RPKI design team is striving for?
>
> Thanks,
>
> Eric
>