Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)

Tim Bruijnzeels <tim@ripe.net> Tue, 19 September 2017 11:54 UTC

Return-Path: <tim@ripe.net>
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 7B65113421B; Tue, 19 Sep 2017 04:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 aaTkiZ4_dIP7; Tue, 19 Sep 2017 04:54:31 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 8BCC41331E7; Tue, 19 Sep 2017 04:54:31 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1duH6f-0000g1-72; Tue, 19 Sep 2017 13:54:26 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-6.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1duH6f-0006kp-3n; Tue, 19 Sep 2017 13:54:25 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <24E0B229-B5C0-446C-BD41-E90234C1C405@nostrum.com>
Date: Tue, 19 Sep 2017 13:54:24 +0200
Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" <draft-ietf-sidr-rpki-validation-reconsidered@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, sidr chairs <sidr-chairs@ietf.org>, The IESG <iesg@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, "Alvaro Retana (aretana)" <aretana@cisco.com>, Terry Manderson <terry.manderson@icann.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA8C1A86-DC5E-4A58-A343-6B24D1055E59@ripe.net>
References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> <BF1750C4-6D9C-4C3B-8B93-7165514711F6@nostrum.com> <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net> <4EAF550B-34F0-4736-AD7B-252DFCF7D58E@nostrum.com> <30E4E5AD-9ECA-4D66-B6EB-99912082EF12@ripe.net> <24E0B229-B5C0-446C-BD41-E90234C1C405@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3273)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719c5c0e98361cdaa0fc60d58b3b6cc75e4
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/CZnoIvfrKcxwQJKSp98cpWe-U-c>
Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 19 Sep 2017 11:54:33 -0000

> On 18 Sep 2017, at 23:36, Ben Campbell <ben@nostrum.com> wrote:
> 
>> 
>> On Sep 18, 2017, at 8:15 AM, Tim Bruijnzeels <tim@ripe.net> wrote:
>> 
>> Hi Ben, all,
>> 
>>> On 15 Sep 2017, at 23:20, Ben Campbell <ben@nostrum.com> wrote:
>>> 
>>> Hi,
>>> 
>>> See comments inline. I apologize in advance if I am just being dense, and I cannot claim to be an expert on how one applies a path validation policy OID in general.
>>> 
>>> 
>>> Thanks!
>>> 
>>> Ben.
>>> 
>>>> On Sep 14, 2017, at 7:00 AM, Tim Bruijnzeels <tim@ripe.net> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Sure. I also proceeded to discuss your and Terry’s points, but apparently not to the desired level of clarity. Let me try again here, and tackle both your and Terry’s discuss items since they are closely related.
>>>> 
>>>>> Is it legal to mix certificate policies in a given cert path? The last
>>>>> paragraph of section 5 implies that you can, but doesn't say so explicitly.
>>>> 
>>>> According to this document it is. Section 4.2.2.4 starts with the following:
>>>> 
>>>> The following is an amended specification for path validation to be
>>>> used in place of section 7.2 of [RFC6487] allowing for the validation
>>>> of both certificates following the profile defined in [RFC6487], as
>>>> well as certificates following the profile described above.
>>>> 
>>>> So the intent here is to describe a single validation algorithm that can be used to validate a chain of old OIDs only (in which case it’s semantically equivalent to the current spec in RFC6487), new OIDs only (as described in the example in 4.3), or indeed a mix - but no example is given on how that works out.
>>>> 
>>>> 
>>>>> If you _can_ mix policies, what happens if you do? If I read the rules in 4.2.4.4.
>>>>> correctly (and it's likely that I am not), if you run into a cert in the chain
>>>>> that does not follow this profile, it's likely to give a null VRS-IP or VRS-AS
>>>>> value, which would seem to invalidate an certificate further down the chain
>>>>> that _does_ follow this policy?
>>>> 
>>>> 
>>>> The “Validated Resource Sets” (VRS-*) are always calculated, regardless of whether the old or new OIDs are used.
>>> 
>>> This is where I am confused. The calculation of VRS is described in this draft in the amendment to the path validation in section 7.2 of 6487. I assumed that the amended path validation procedure only applies with the “new” OID. Is that incorrect? If so, can you point to the text that states that? (It’s entirely possible I missed something, or completely misunderstand how the OIDs are applied. )
>> 
>> First paragraph of 4.2.2.4:
>> 
>> "The following is an amended specification for path validation to be used in place of section 7.2 of [RFC6487]
>> allowing for the validation of both certificates following the profile defined in [RFC6487], as well as certificates
>> following the profile described above."
>> 
>> So, yes, as far as I am concerned the intent was to have this cover both the old and new OIDs. Where the algorithm if applied to old OID only is semantically equivalent to section 7.2 of RFC6487 - or at least: it has the same outcome.
>> 
> 
> That intent surprises me, I was under the impression the entire document was specific to the new OIDs. This seems to be supported by this text in the abstract:
> 
> "The use of this updated procedure is signalled by form of a set of alternative Object Identifiers (OIDs) indicating that the alternative version of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure ( RFC 6484) defined in this document should be used.”
> 
> … and in the specific case of the certificate validation policy OID, there is this text in 4.2.1:
> 
> "This alternative Certificate Policy is the same as the Certificate Policy described in [
> RFC6484], except that it indicates that the validation rules described in
> Section 4.2.4.4 are to be used.”
> 
> If the rules in 4.2.4.4 are used even when that OID is not present, then I’m confused about what the OID signals in the first place.

The OIDs are used to drive a decision in the rules described in 4.2.4.4.
= Old OIDs -> reject over-claim, this has the same result as section 7.2 in RFC6487
= New OIDs -> warn on over-claim

So as far as clarity goes, it might be better to either leave out the set regarding the need for the different OIDs in their respective sections, or say “This OID is used to in the decision process of the validation rules described in 4.2.4.4.

>> If this needs to be more explicit I am happy to accept a suggestion - as an author knowing my own intentions, it’s not always trivial to see how others would interpret text differently.
> 
> I’m not sure this is just a matter of clarification. The text I mention above explicitly says the OID signals the use of the amended CP. I have to assume that was the working group intent, and what was understood by people during IETF LC. If that is _not_ the intent, we would need some degree of consensus to change that text. ( I suspect that would mean going back to the WG or IETF LC, but I will leave that to Alvaro to decide.)
> 

It was my assumption that my intent was clear.

But I will accept whatever Alvaro decides on this.


> My strictly personal opinion is that it would be _really_ confusing to have some aspects of the new CP apply even when the new OID is not used.

The assumption on my part here was that RPs can decide to support this RFC-to-be and then use section 4.2.4.4 to validate old and new CP alike.

The process described in 4.2.4.4 when used for old OIDs only has the same outcome as section 7.2 of RFC 6487. It’s true that “Validated Resource Sets” are not named in RFC6487, but in a tree where only old OIDs are used one will find that the Validated Resource Set for a given *valid* certificate always matches the certificate itself.

Thanks
Tim


> 
> Thanks,
> 
> Ben.