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

Tim Bruijnzeels <> Wed, 13 September 2017 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A89A132F31; Wed, 13 Sep 2017 07:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YVXA2cFH2G92; Wed, 13 Sep 2017 07:20:29 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62AB51321A0; Wed, 13 Sep 2017 07:20:29 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <>) id 1ds8Wc-000Age-79; Wed, 13 Sep 2017 16:20:24 +0200
Received: from ([] by with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <>) id 1ds8Wc-0002wh-2u; Wed, 13 Sep 2017 16:20:22 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Wed, 13 Sep 2017 16:20:21 +0200
Cc: The IESG <>, Chris Morrow <>, sidr chairs <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ben Campbell <>
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
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e826c1347a9c9e6f41cb806eb3450c0f
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 14:20:32 -0000


My apologies for the delay - I am just back from a late summer holiday.

Let me address the DISCUSS is in this, and Terry Manderson’s email, first.

> On 29 Aug 2017, at 04:36, Ben Campbell <> wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.

The current document leaves the OID as a per certificate choice and provides a validation model that can be used in either case. In either case the VRS-IP/AS are calculated as described in item #7. Under item #8, the VRS-IP/AS is then compared again to the certificate to determine if it was ‘over-claiming’ compared to its acceptable VRS-IP/AS set. The OID choice determines whether this results in a warning about such over claiming resources, or rejecting. The algorithm defined here when only old OIDs are used is semantically equivalent to section 7.2 of RFC6847.

Note that item #7 does not have explicit text on the case where ‘inherit’ is used, but I believe that this is technically covered by the text in sections and of RFC3779. Essentially: the value of the signing certificate applies, use recursion if that also uses inherit.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Substantive:
> - General: There's a lot of amending going on here--does this draft really not
> update any RFCs (e.g. 6487)?
> -
> -- "Any extension not thus identified MUST NOT appear in
>       certificate x." (Repeats multiple times)
> That seems to prevent future extensibility. Is that the intent?
> -- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT
>       appear on a CRL issued by the CA represented by certificate x-1"
> Is this intended as a requirement to check CRLs? If so, please say that
> explicitly.
> Editorial:
> - The third paragraph seems redundant to the first paragraph (pattern
> repeats in several sections.)he
> - "Either the IP Resources extension, or the AS Resources extension, or
>   both, MUST be present in all RPKI certificates, and if present, MUST
>   be marked critical."
> "... and if present..." seems redundant, since the previous clause said one
> MUST be present.
> - "... values are NOT supported..."
> a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the
> all-caps is just for emphasis, but we typically reserve that for RFC 2119
> keywords.
> - :
> -- "Certificate validation requires verifying that all of the following
>   conditions hold, in addition to the certification path validation
>   criteria specified in Section 6 of [RFC5280]."
> The "... in addition to..." part doesn't seem quite true. For example, making
> sure the current date fits in the active range, ensuring a cert is signed by
> the issuer, etc.  are already covered in 5280.
> - - "...certificate MUST contain all
>       extensions defined in section 4.8 of [RFC6487] that must be
>       present."
> That seems tautologically true. If this is a statement of fact, then please
> avoid the MUST. If this is really a new normative requirement, then I'm
> confused at the intent.
> -- "all extensions defined in section 4.8 of
>       [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be
>       present. "
> It would be more reader-friendly to mention what extensions are defined in
> 4.8.9.
> -- "7. Compute the VRS-IP and VRS-AS set values as indicated below:"
> Inconsistent voice.
> -- list entry 7, 4th bullet: "If the IP Address Delegation extension is present
> in
>          certificate x and x=1, set the VRS-IP to the resources found
>          in this extension."
> That seems identical to the first bullet. Should it has said "AS Address
> Delegation extension"?
> _______________________________________________
> sidr mailing list