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, 09 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.
- Re: [sidr] I-D Action: draft-ietf-sidr-rpki-valid… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-rpki-valid… Sean Turner
- [sidr] I-D Action: draft-ietf-sidr-rpki-validatio… internet-drafts
- Re: [sidr] I-D Action: draft-ietf-sidr-rpki-valid… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-rpki-valid… Sandra Murphy
- Re: [sidr] I-D Action: draft-ietf-sidr-rpki-valid… Sean Turner
- Re: [sidr] I-D Action: draft-ietf-sidr-rpki-valid… Stephen Kent
- Re: [sidr] I-D Action: draft-ietf-sidr-rpki-valid… Tim Bruijnzeels