Tim,
Your explanation does lay it out more clearly, and it is consistent with how I
understood it before.
However, I have two questions/suggestions:
1. A question/suggestion about the new validation algorithm:
Consider the following cert-chain, ROA example:
TA: {5.0.0.0/8, 8.0.0.0/12, AS1-AS100}
CA1: {5.0.0.0/20, 8.0.0.0/18, AS1-AS400}
CA2: {5.0.0.0/24, 8.0.0.0/20, AS1-AS50} <-- note the "narrowing" of sub-cone
in the 5.0.0.0/x space
CA3: {5.0.0.0/22, 8.0.0.0/22, AS1-AS500} <-- note the "widening" of sub-cone
in the 5.0.0.0/x space
CA4: {5.0.0.0/24, 8.0.0.0/24, AS1-AS5}
(Hint: picture specific-resource sub-cones within the broader cone of varied
resources)
The EE certs are:
EE1: {5.0.0.0/24} generated from CA4
EE2: {8.0.0.0/24} generated from CA4
And the ROAs are:
ROA1: {5.0.0.0/24, AS1000} (signed with EE1)
ROA2: {8.0.0.0/24, AS2000} (signed with EE2)
I think your proposed validation algorithm would determine that
EE1, EE2, ROA1 and ROA2 are all valid.
However, if you require that the specific resource (e.g. 5.0.0.0/24) -- that is
relevant
to the ROA or the EE cert being validated -- MUST have a “non-narrowing
sub-cone”
in the cert chain resources, then EE2 and RAO2 will be still valid,
but EE1 and ROA1 will be invalid.
By “non-narrowing sub-cone” (for a specific resource/prefix), I mean the
following:
As we move up the cert-chain, the “relevant” or “corresponding”
prefixes (relative to the specific prefix in consideration) seen at each level
in the hierarchy of certs must be such that the same prefix or a less specific
is found at each level relative to the level directly below.
As you can see in the example, non-narrowing sub-cone is true for 8.0.0.0/24
(EE2),
but not for 5.0.0.0/24 (EE1). Hence, EE1 and ROA1 are invalid (under this
enhancement).
Do you think there merit in this approach over what you have now in validation
reconsidered?
This somewhat less lenient approach would seem a bit more sensible (at least in
my mind).
2. How do you perform the validation of a CRL?
How is it similar to or different from how you validate a ROA?
How do you walk the certificate hierarchy in the case of a CRL validation
process?
I.e. How are the "encompassing" rules applied?
I think this should be explicitly explained/clarified in the document.
Sriram
________________________________________
From: sidr <sidr-boun...@ietf.org> on behalf of Tim Bruijnzeels <t...@ripe.net>
Sent: Thursday, November 26, 2015 7:29 AM
To: Stephen Kent
Cc: sidr
Subject: Re: [sidr] Validation Reconsidered (again/again) question
Hi,
> On 25 Nov 2015, at 21:19, Stephen Kent <k...@bbn.com> wrote:
>
> None of those who believe that this draft is a good thing seem to have
> addressed
> an issue I raised a while ago; the proposed solution is ill-defined and, the
> most
> likely interpretation doesn't seem to work, in general. I'll try to explain
> this
> reasoning, again, and provide an example.
I believe the draft is being precise, but in the process has become difficult
to parse. Let me attempt once more to explain the proposal in a different way:
"When doing top-down validation of resource certificates in the RPKI we propose
that rather than rejecting a certificate that has resources not held by the
parent (but is valid on all other respects), we would accept the certificate
but keep note of the actual resources we believe it can be authoritative for.
I.e. the intersection of resources on this certificate and the resources
accepted for the parent. The RP SHOULD however issue a warning in case certain
resources are excluded because of this, so that the responsible CA can fix the
situation.
Please note that for ROAs there is a requirement that all ROA prefixes are
included on the EE certificate of the (ROA) signed object CMS. This proposal
does not change this. A ROA that has prefixes that were removed for whatever
reason higher in the path would still become invalid using this algorithm. We
would therefore RECOMMEND that CAs issue 1 ROA for each prefix, and avoid fate
sharing. That way only ROAs for prefixes that were removed will be affected."
Essentially that really is all there is to it. If this is easier to parse, and
the co-chairs conclude that work should continue, then I am happy to use this
line of explanation in a next version of the document. And no, I have no doubt
that it will need more detail than above in an I-D - but it's the basic
principle that I am trying to convey here.
Tim
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
