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.
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 <b...@nostrum.com> 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) <aret...@cisco.com>
>> 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"
>> <sidr-boun...@ietf.org on behalf of t...@ripe.net> 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.
>>
>>
>>
>
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
