Re: [sidr] RPKI <-> allocation consistency

Eric Osterweil <eosterweil@verisign.com> Mon, 27 August 2012 18:07 UTC

Return-Path: <eosterweil@verisign.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 A316B21F8565 for <sidr@ietfa.amsl.com>; Mon, 27 Aug 2012 11:07:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.339
X-Spam-Level:
X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 VutPEXLgIara for <sidr@ietfa.amsl.com>; Mon, 27 Aug 2012 11:07:10 -0700 (PDT)
Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id D0AE721F855D for <sidr@ietf.org>; Mon, 27 Aug 2012 11:07:09 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUDu3SiExSEYCGhCXjwBo1eI6rpxrJt9L@postini.com; Mon, 27 Aug 2012 11:07:09 PDT
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q7RI72He009822; Mon, 27 Aug 2012 14:07:06 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Aug 2012 14:07:02 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <50389897.3040503@bbn.com>
Date: Mon, 27 Aug 2012 14:07:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <D857A4BB-E484-45A4-A09F-FB8FAF2215AC@tcb.net> <C5B88834-3A10-41F7-A4F3-2B7C9B540197@verisign.com> <50389897.3040503@bbn.com>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 27 Aug 2012 18:07:02.0058 (UTC) FILETIME=[C21600A0:01CD847E]
Cc: sidr@ietf.org
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: Mon, 27 Aug 2012 18:07:10 -0000

Thanks Steve, this is very helpful!

However, I was also referring to the consistency model as viewed by the RPs.  I think this wasn't clear in my email, sorry.  Clearly the structure served by CAs (which you outlined below) is a critical first step.  To that point, I think I mentioned some of this in a follow-on email to this thread.  However, I think the consistency model of the RPs (i.e. will they all have the same view/time ordered view/partial view/etc. of these certs) is an important consideration too, right?

Eric

On Aug 25, 2012, at 5:19 AM, Stephen Kent wrote:

> 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:
>  
>    o  an 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
>> 
>> 
>