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

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 13 Sep 2017 16:20:21 +0200

Hi,

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 <[email-masked]> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 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 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?
> 
> 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 4.2.2.4 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 2.2.3.5 and 3.2.3.3 of RFC3779. Essentially: the value of the signing certificate applies, use recursion if that also uses inherit.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Substantive:
> 
> - General: There's a lot of amending going on here--does this draft really not
> update any RFCs (e.g. 6487)?
> 
> - 4.2.4.4:
> -- "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:
> 
> -4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern
> repeats in several sections.)he
> 
> - 4.2.4.3: "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.
> 
> - 4.3.4.3: "... 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.
> 
> - 4.2.4.4 :
> -- "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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 13 Sep 2017 15:57:45 +0000

[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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Sep 2017 16:18:24 -0500

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.

Thanks!

Ben.

> On Sep 13, 2017, at 10:57 AM, Alvaro Retana (aretana) <[email-masked]> wrote:
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 14 Sep 2017 14:00:40 +0200

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.

> 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.

The “Validated Resource Sets” (VRS-*) are always calculated, regardless of whether the old or new OIDs are used.

If no ‘over-claims’ are found (still very much the intended normal) the validation result will be the same whether old OIDs only, new OIDs only, or a mix of OIDs are used.

In case over-claims do exist then it depends on whether the certificate under inspection uses the new OIDs or not. In case it doesn’t, it will be rejected and things behave as in RFC6487. In case it does, then the intersection of resources is still accepted. Any certificates issued further down the tree that also include these over-claimed resource would then be rejected if they happen to use the old OIDs, or if they use the new OIDs the intersection of quoted resources and the VRS-* of the issuing certificate would be accepted. 

I can illustrate by example, and if desired extend section 4.3 with this:

   Consider the following example where a mix of old and new OIDs are used in the RPKI tree:

     Certificate 1 (TA):
      OID: NEW
      Issuer TA,
      Subject TA,
      Resources 192.0.2.0/24, 198.51.100.0/24,
                2001:db8::/32, AS64496-AS64500

       Verified Resource Set: 192.0.2.0/24, 198.51.100.0/24,
                              2001:db8::/32, AS64496-AS64500
       Warnings: none

       NOTE: The choice of OID is irrelevant for the TA. By definition, it cannot be over-claiming.

     Certificate 2 (CA1):
      Issuer TA,
      Subject CA1,
      OID: OLD
      Resources 192.0.2.0/24, 2001:db8::/32, AS64496

       Verified Resource Set: 192.0.2.0/24,
                              2001:db8::/32, AS64496
       Warnings: none

     Certificate 3 (CA2):
      Issuer CA1,
      Subject CA2,
      OID: NEW
      Resources 192.0.2.0/24, 198.51.100.0/24, AS64496

       Verified Resource Set: 192.0.2.0/24, AS64496
       Warnings: over-claim for 198.51.100.0/24

       NOTE: Even though Certificate 2 used the old OIDs, Certificate 3 can be accepted with a reduced VRS since it uses the new OIDs.

     Certificate 4 (CA3):
      Issuer CA2,
      Subject CA3,
      OID: NEW
      Resources 192.0.2.0/24

       Verified Resource Set: 192.0.2.0/24
       Warnings: none

     Certificate 5 (CA4):
      Issuer CA2,
      Subject CA4
      OID: NEW
      Resources 198.51.100.0/24

       Verified Resource Set: empty
       Warnings: 198.51.100.0/24

       Note: The accepted VRS-* contains no resources. So even if the certificate itself is accepted, its key cannot be used
                 to make valid assertions about any resources.

     ROA 1 for CA3 (valid):
      Embedded Certificate R1 (EE certificate):
       Issuer CA4,
       Subject R1,
       OID: OLD
       Resources 192.0.2.0/24

        Verified Resource Set: 192.0.2.0/24
        Warnings: none

        Prefix 192.0.2.0/24, Max Length 24, ASN 64496

       ROA1 is considered valid because the prefix matches the Verified
       Resource Set on the embedded EE certificate.

     ROA 2 for CA3 (invalid):
      Embedded Certificate R2 (EE certificate invalid):
       Issuer CA2,
       Subject R2,
       OID: OLD
       Resources 198.51.100.0/24

        Verified Resource Set: none (certificate is rejected)
        Warnings: none (certificate rejected)

        Prefix 198.51.100.0/24, Max Length 24, ASN 64496

       ROA2 is considered invalid because the embedded EE certificate is
       considered invalid.

     ROA 3 for CA4 (invalid):
      Embedded Certificate R3 (EE certificate invalid):
       Issuer CA2,
       Subject R3,
       OID: NEW
       Resources 198.51.100.0/24

        Verified Resource Set: empty
        Warnings: 198.51.100.0/24

        Prefix 198.51.100.0/24, Max Length 24, ASN 64496

       ROA3 is considered invalid because the prefix is not included in the
       empty VRS.

       Note: since all ROA Prefixes need to be in the VRS-* for the
                ROA to be valid, it might make sense to simply mandate
                old OIDs on ROA EE certificates.

I hope this clarifies. But please let me know if it doesn’t, and thank you for helping to clarify the document.

Tim

> On 13 Sep 2017, at 23:18, Ben Campbell <[email-masked]> wrote:
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 15 Sep 2017 16:20:09 -0500

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 <[email-masked]> wrote:
> 
> Hi,
> 

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. )

If that assumption was correct, then I would assume the VRS for a cert using the old OID would be undefined, and that if cert X has an undefined VRS. (comment continued in the example below…)

>       Verified Resource Set: 192.0.2.0/24,

It’s not clear to me why the VRS is set to that in the cert with the old OID. Does the amended validation process in this draft apply for certs that do not use the new OID? If not, wouldn’t the VRS here be null, undefined, or simply non-existant?

>       NOTE: Even though Certificate 2 used the old OIDs, Certificate 3 can be accepted with a reduced VRS since it uses the new OIDs.

Continuing with the assumption that the VRS in cert 2 is undefined, doesn’t that make the VRS in cert 3 the intersection of "192.0.2.0/24, 198.51.100.0/24” and the undefined VRS from Cert 2? How is the result of that something other than a null set, which would then propagate down the chain as as you calculate each set intersection?

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 18 Sep 2017 15:15:44 +0200

Hi Ben, all,

> On 15 Sep 2017, at 23:20, Ben Campbell <[email-masked]> wrote:
> 
> Hi,
> 

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.

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.

Kind regards

Tim Bruijnzeels

---

From: Ben Campbell <[email-masked]>
Date: Mon, 18 Sep 2017 16:36:12 -0500

> On Sep 18, 2017, at 8:15 AM, Tim Bruijnzeels <[email-masked]> wrote:
> 
> Hi Ben, all,
> 

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.

> 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.)

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.

Thanks,

Ben.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 19 Sep 2017 13:54:24 +0200

> On 18 Sep 2017, at 23:36, Ben Campbell <[email-masked]> wrote:
> 
>> 

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.

> 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…

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 22 Sep 2017 15:56:10 -0500

> On Sep 19, 2017, at 6:54 AM, Tim Bruijnzeels <[email-masked]> wrote:
> 
> 

Are you suggesting the text “should” say that, or “does” say that? As written, the OID seems to drive the selection about whether you use the rules in 4.2.4.4 or not. But I think you are saying that, if you implement these OIDs, you SHOULD/MAY use the rules in 4.2.4.4 all the time, but use the OID as an input to those rules. Is that correct?

> 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…

I’m not sure what you mean by the former. If you go with the latter, then the rules in 4.2.4.4 will need to be explicit in how the OID is used in that process.

> 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…

As I mentioned above, if the idea is to always use the rules in 4.2.4.4, and use the OID to drive decisions _within_ those rules, the rules need to be updated with the explicit details.