Re: [sidr] Validation Reconsidered (again/again) question

Stephen Kent <kent@bbn.com> Thu, 07 January 2016 17:18 UTC

Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE7D1A9102 for <sidr@ietfa.amsl.com>; Thu, 7 Jan 2016 09:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv044exuEAMH for <sidr@ietfa.amsl.com>; Thu, 7 Jan 2016 09:18:13 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B67E1A9100 for <sidr@ietf.org>; Thu, 7 Jan 2016 09:18:13 -0800 (PST)
Received: from ssh.bbn.com ([192.1.122.15]:49710 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1aHECR-0007Kc-WE; Thu, 07 Jan 2016 12:18:12 -0500
From: Stephen Kent <kent@bbn.com>
To: Geoff Huston <gih902@gmail.com>
References: <565617E8.4070005@bbn.com> <E65211E9-4307-434C-B916-C3355968CE48@gmail.com>
Message-ID: <568E9DD3.2040403@bbn.com>
Date: Thu, 07 Jan 2016 12:18:11 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <E65211E9-4307-434C-B916-C3355968CE48@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/kZNwQQ-9oM7V61YNvUy3HmZQxAc>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] Validation Reconsidered (again/again) question
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 07 Jan 2016 17:18:18 -0000

Geoff,

Happy new year.


> ...
>
>> Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for a ROA.
>>
>> TA->CA 1->CA 2->ROA
>>
>>
>> Assume the TA cert contains address space T, U, V, W, X, Y and Z.
>>
>> Assume the CA 1 cert contains address space T, U, V, and W.
>>
>> Assume the CA 2 cert contains address space V and W.
>>
>> Let's say that the ROA EE cert issued by CA 2 contains address space V.
>>
>> CA 2 is about to receive address space Z from some other ISP, so it has asked
>> CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 agrees,
>> and issues a new cert to CA 2 and that cert contains address space V and Z.
> CA1 has already issued a cert with subject “CA2” and resources (V,W) - lets call this cert No 1
>
> Do you mean:
>
> a) CA 1 issues a cert  with subject “CA2” and resources (V,Z) - lets call this cert No 2
>
> OR the combination of actions:
>
> b)    CA 1 issues a SECOND cert  with subject “CA2” and resources (V,Z)  - lets call this Cert No 2
>     AND
>        CA1 revokes the cert with subject “CA2” and resources (V,W) (which we call Cert No 1)
I intended the second case. Chris pointed out to me in a private message 
that
I failed to include W in this cert; my bad. I intended to have the new 
cert add Z to V and W.
>> Now, under the assumption about what "specific resource set" means, when
>> an RP tries to validate CA 2's ROA,
> Now I’m confused - originally the ROA was signed by an EE cert issued by CA 2’s Cert No 1
>
> so when you refer to CA 2’s ROA do you mean the ROA that was signed by an EE cert issued by CA 2’s Cert No 1,
> or do you mean a new ROA signed by an EE issued by CA 2’s Cert No 2?
No ROA is "signed" by any cert; a signature on a ROA (or a cert) is 
verified using a cert.

The ROA to which I refer is issued under CA 2 (your Cert 1), and it is 
not new.
I described the ROA when I trued to set the stage for the example:
     "Let's say that the ROA EE cert issued by CA 2 contains address 
space V."
>> the "specific resource set" will be V, and
>> so it will be valid, because V is in all of the certs from the TA through CA 1
>> to CA 2. Even though CA 2's cert contains Z, which is not contained
>> in CA 1's cert, this will not be considered in the validation of the ROA EE cert.
>> This is the desired outcome, because CA 2 has begun the process of getting its
>> new address space (Z), but that process has not broken its CA cert. I assume this
>> is an example of the reduced fragility that is so appealing.
> So I _think_ you are assuming that there is a new ROA, signed by an EE cert issued by
> the CA that has a CA cert issued by CA 1 with resources (V,Z), and evidently you are referring
> to this new ROA and its new EE cert.
no, it's the same ROA I defined in the intro to the example.

I'll stop at this point, because the remainder of your comments are
based on the assumption that this was a new ROA, which was not my intent.

Sorry for the typo in the resource set for "Cert 1" and for not being
more explicit in saying that the new Cert for CA 2 was issued by CA 1
as a replacement for the original CA 2 cert.

Steve