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

[Ben Campbell <[e-mail]>]

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 <[e-mail]> 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. )

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


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

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?


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

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?

> 
> 
>     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 <[e-mail]> wrote:
>> 
>> 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) <[e-mail]> 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" <[e-mail] on behalf of [e-mail]> wrote:
>>> 
>>>> ----------------------------------------------------------------------
>>>> 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.
>>> 
>>> 
>>> 
>> 
>