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

Ben Campbell <> Wed, 13 September 2017 21:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8935A132F2A; Wed, 13 Sep 2017 14:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4HwQ40AYsu6L; Wed, 13 Sep 2017 14:18:53 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6CF9813293A; Wed, 13 Sep 2017 14:18:53 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v8DLIQSZ075788 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Sep 2017 16:18:26 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_145F40C7-405D-43B0-A65D-A511E92225FC"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 13 Sep 2017 16:18:24 -0500
In-Reply-To: <>
Cc: Tim Bruijnzeels <>, Terry Manderson <>, Chris Morrow <>, sidr chairs <>, "" <>, The IESG <>, "" <>
To: "Alvaro Retana (aretana)" <>
References: <> <> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Sep 2017 21:18:56 -0000

Alvaro’s interpretation is indeed what I meant. My concern is with what works and what doesn’t work with the basic mechanism. How it will get used in practice is a related, but different, issue.



> On Sep 13, 2017, at 10:57 AM, Alvaro Retana (aretana) <> wrote:
> [Explicitly adding Terry…]
> Tim:
> Hi!
> As I think you understand from the response below, there are two parts to consider when deploying: what can be done, and what will be done.  Interpreting what Ben and Terry wrote…what I think they are asking is for you to clarify in this document the considerations around mixing policies.  For example (to borrow from Terry), if a “TA has a particular OID and down the tree an issued certificate has a different OID”, what are the implications/problems/etc.?
> Note that this question is different from the document defining how things may end up being deployed later (“whether this is an acceptable deployment model”).  The actual deployment discussions (as in, this is what we’re going to do and when) should happen in sidrops.
> Thanks!
> Alvaro.
> On 9/13/17, 10:20 AM, "sidr on behalf of Tim Bruijnzeels" < on behalf of> wrote:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> This is probably just a matter of me being dense, but I'd like to understand
>> what I am missing:
>> 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. If
>> you _can_ mix policies, what happens if you do? If I read the rules in
>> 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?
>> So, I guess it comes down to the following: If mixed policies are allowed, how
>> does that work? If mixed policies are not allowed, there needs to be text that
>> says that. It's quite possible such text exists (here or elsewhere), and I
>> missed it.
> First of all it was my understanding that there was an agreement with the AD that actual deployment should be discussed in sidrops. So this document serves as a benchmark to describe the alternative algorithm. In my opinion a mix is supported by this document, but the choice whether this is an acceptable deployment model can be discussed later.