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

Stephen Kent <> Sat, 09 July 2016 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C241D12D108 for <>; Sat, 9 Jul 2016 15:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.02
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bCQKw1_UP_PD for <>; Sat, 9 Jul 2016 15:12:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C010312B055 for <>; Sat, 9 Jul 2016 15:12:34 -0700 (PDT)
Received: from ( []) by (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 ([]) by (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 for <>; Sat, 9 Jul 2016 22:12:30 GMT
Received: from ([]:49335) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1bM0U8-000BQX-Kj for; Sat, 09 Jul 2016 18:12:29 -0400
References: <> <>
From: Stephen Kent <>
Message-ID: <>
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: <>
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-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


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 

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.