Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ) 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> From: Stephen Kent 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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 22:12:37 -0000 This is a multi-part message in MIME format. --------------C8EDA8143706220C96450FBF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. --------------C8EDA8143706220C96450FBF Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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 issuing certificate.  ROA1 is valid because the specified prefix is encompassed 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.


--------------C8EDA8143706220C96450FBF--