Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt

Stephen Kent <kent@bbn.com> Sat, 09 July 2016 22:12 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 C241D12D108 for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2016 15:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.02
X-Spam-Level:
X-Spam-Status: No, score=-5.02 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 bCQKw1_UP_PD for <sidr@ietfa.amsl.com>; Sat, 9 Jul 2016 15:12:35 -0700 (PDT)
Received: from bos-mailout2.raytheon.com (bos-mailout2.raytheon.com [199.46.198.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C010312B055 for <sidr@ietf.org>; Sat, 9 Jul 2016 15:12:34 -0700 (PDT)
Received: from ma-mailout1.directory.ray.com (ma-mailout1.directory.ray.com [147.25.130.100]) by bos-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u69MCWbw000560 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <sidr@ietf.org>; Sat, 9 Jul 2016 22:12:33 GMT
Received: from smtp.bbn.com ([128.33.1.81]) by ma-mailout1.directory.ray.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u69MCT0s031808 (using TLSv1 with cipher DHE-RSA-AES256-SHA(256 bits) verified NO) sender kent@bbn.com for <sidr@ietf.org>; Sat, 9 Jul 2016 22:12:30 GMT
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49335) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1bM0U8-000BQX-Kj for sidr@ietf.org; Sat, 09 Jul 2016 18:12:29 -0400
To: sidr@ietf.org
References: <20160708091943.32156.30842.idtracker@ietfa.amsl.com> <C570AE8F-A764-43ED-B273-005DABBDC836@ripe.net>
From: Stephen Kent <kent@bbn.com>
Message-ID: <8955af42-c592-20fc-edd4-b06c7b677dda@bbn.com>
Date: Sat, 9 Jul 2016 18:12:28 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <C570AE8F-A764-43ED-B273-005DABBDC836@ripe.net>
Content-Type: multipart/alternative; boundary="------------C8EDA8143706220C96450FBF"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-09_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=13 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607090251
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/wv-niqn3duEYxn8M6G0Tc_a-j20>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-06.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 09 Jul 2016 22:12:37 -0000

Tim,

I have not yet read the -06 version, but I did notice a couple of issues 
in the 7.2 text I provided, most of which you adopted. Specifically, I 
think it useful to refer to 3779 in Section 2 in the 2nd paragraph, and 
at the end:

These criteria require, in particular, that the Internet Number

Resources (INRs) of each certificate in the validation path are

"encompassed" by INRs on the issuing certificate.(This criteria

    is derived from [RFC3779], which defines the certificate extensions

    used to represent INRs.) The first

certificate in the path is required to be a trust anchor, and its

resources are considered valid by definition.



All certificates in this scenario are considered valid (relative to 
[RFC3779] since the INRs in each certificate are encompassed by

those of the issuingcertificate.ROA1 is valid because the specified 
prefix isencompassed by the embedded EE certificate, as required by 
[RFC6482].



I copied text that was OK when it appeared in 6487, but now needs to 
refer to 6487:

     3.The Version, Issuer, and Subject fields of certificate x satisfy

the constraints established in Section 4.1-4.7 of [RFC6487].

4.Certificate x contains all the extensions that MUST be present,

as defined in Section 4.8 of [RFC6487].The value(s)

for each of these extensions MUST be satisfy the constraints

established for each extension in the respective sections.Any

extension not identified in Section 4.8 MUST NOT appear in

certificate x.

step 6 could be a bit be clearer with a minor edit:


6.If certificate x is an EE certificate, then the INRs of this

certificate MUST be "encompassed" by the values of VRS-IP and

VRS-AS computed for certificate x-1.


also, the loop sentence disappeared, so I added it after the last bullet 
in step 7:


Otherwise, return to step 1 and continue path validation.