Re: [sidr] Validation Reconsidered (again/again) question

[Carlos M. Martinez]

Aside from process questions (whether should the draft update a standard
or nor), I definitely believe the WG should continue working on this.

-Carlos

On 11/6/15 10:52 AM, Christopher Morrow wrote:
> Please take 2 weeks time to consider:
> 
> "This document was adopted as a WG work item, should we accept this
> change and complete the work or not?"
> 
> where:
>   'this document' is:
>
> 
> 
> I'll close the mic line on: 11/20/2015
> Nov 20, 2015
> 
> -Chris
> sidr-co-chair
> 
> ___
> 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

Re: [sidr] Validation Reconsidered (again/again) question

[Tim Bruijnzeels]

> On 06 Nov 2015, at 10:56, Carlos M. Martinez  wrote:
> 
> Aside from process questions (whether should the draft update a standard
> or nor), I definitely believe the WG should continue working on this.
+1

Tim

> 
> -Carlos
> 
> On 11/6/15 10:52 AM, Christopher Morrow wrote:
>> Please take 2 weeks time to consider:
>> 
>> "This document was adopted as a WG work item, should we accept this
>> change and complete the work or not?"
>> 
>> where:
>>  'this document' is:
>>   
>> 
>> 
>> I'll close the mic line on: 11/20/2015
>>Nov 20, 2015
>> 
>> -Chris
>> sidr-co-chair
>> 
>> ___
>> 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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Geoff Huston]

> On 6 Nov 2015, at 12:52 PM, Christopher Morrow  
> wrote:
> 
> Please take 2 weeks time to consider:
> 
> "This document was adopted as a WG work item, should we accept this
> change and complete the work or not?”
> 

I say “Yes," for some value of somebody/some people completing the work that is 
!= me


thanks,

  Geoff


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Arturo Servin]

+ 1 for adoption.

And hopefully somebody would say "I take this".

Regards
as



On Thu, 5 Nov 2015 at 23:04 Geoff Huston  wrote:

>
> > On 6 Nov 2015, at 12:52 PM, Christopher Morrow <
> christopher.mor...@gmail.com> wrote:
> >
> > Please take 2 weeks time to consider:
> >
> > "This document was adopted as a WG work item, should we accept this
> > change and complete the work or not?”
> >
>
> I say “Yes," for some value of somebody/some people completing the work
> that is != me
>
>
> thanks,
>
>   Geoff
>
>
> ___
> 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

Re: [sidr] Validation Reconsidered (again/again) question

[Stephen Kent]

Please take 2 weeks time to consider:

"This document was adopted as a WG work item, should we accept this
change and complete the work or not?"

Adopting a doc as a WG item does not mean that it is acceptable
"as is"  at the time it was adopted. The intent is that the author(s)
will cooperate with WG members to refine the doc as comments are posted.

This doc has received detailed comments, posted to the list, to which the
authors have never deigned to respond. It is very poorly written, and the
specific change it describes (vaguely) is not technically consistent with
the part of RFC (6487) that it purports to be updating.

So, unless the folks who volunteered to assume responsibility for the doc
(all of whom were already listed as co-authors) are prepared to do a much
better job in addressing these shortcomings, I object to continuing with 
this work.


Steve


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[mcr]

I am opposed to this document for the reasons stated by Steve Kent and others. 


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Oleg Muravskiy]

On Fri, Nov 06, 2015 at 12:52:13PM +1100, Christopher Morrow wrote:
> Please take 2 weeks time to consider:
> 
> "This document was adopted as a WG work item, should we accept this
> change and complete the work or not?"

Yes, we should.

> 
> where:
>   'this document' is:
>
> 
> 
> I'll close the mic line on: 11/20/2015
> Nov 20, 2015
> 
> -Chris
> sidr-co-chair
> 
> ___
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> 

-- 
Oleg Muravskiy
RIPE NCC

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Samuel Weiler]

"This document was adopted as a WG work item, should we accept this
change and complete the work or not?"


Yes.  I believe this change in the validation algorithm improves the 
operational robustness of the RPKI.


If the WG chairs find themselves uncertain about the consensus on this 
quesiton, it might be helpful to ask ourselves: if we had chosen a 
certificate structure other than X.509, perhaps even something invented 
specifically for the purpose, would we be hesitating to make this change? 
At the very least, that could bring the discussion back to specific 
operational issues, which would, IMHO, be a good focus for it.


Hopefully the chairs will see a consensus without needing to ask that 
question - the discussion I've read here suggests to me that we have at 
least a rough consensus.


-- Sam

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Samuel Weiler]

On Fri, 6 Nov 2015, Stephen Kent wrote:

So, unless the folks who volunteered to assume responsibility for the 
doc (all of whom were already listed as co-authors) are prepared to do a 
much better job in addressing these shortcomings, I object to continuing 
with this work.


It sounds like you're objecting to the work because the editors of this WG 
draft have been insufficiently responsive to your criticisms.


That sounds like a WG management issue, and I am disappointed that you 
would ask the WG to abandon useful work because of it.


I take the view that document editors have been given the task of 
documenting the consensus of a WG.  If you think the editors aren't 
documenting consensus correctly or are just doing a poor job with the 
writing, take it up with the chairs.  It might be helpful to recruit some 
alternative editors, particularly ones who don't seem to have a strong 
bias re: the topic - finding good document editors is a persistent problem 
in many WGs.  At the same time, recognize that if you're too far in the 
rough (which you might be), your own criticisms may not result in changes 
to the doc.


-- Sam

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Stephen Kent]

Sam,


On Fri, 6 Nov 2015, Stephen Kent wrote:

So, unless the folks who volunteered to assume responsibility for the 
doc (all of whom were already listed as co-authors) are prepared to 
do a much better job in addressing these shortcomings, I object to 
continuing with this work.


It sounds like you're objecting to the work because the editors of 
this WG draft have been insufficiently responsive to your criticisms.
Non-responsive to specific suggested changes and noted technical flaws 
would be more accurate.


That sounds like a WG management issue, and I am disappointed that you 
would ask the WG to abandon useful work because of it.
Perhaps you have not been following this thread closely. Geoff said that 
he didn't
want to continue as document editor, and that triggered the call by thew 
WG chairs
as to whether the doc should die. I didn't initiate that question; I 
replied to it.
I take the view that document editors have been given the task of 
documenting the consensus of a WG.  If you think the editors aren't 
documenting consensus correctly or are just doing a poor job with the 
writing, take it up with the chairs.  It might be helpful to recruit 
some alternative editors, particularly ones who don't seem to have a 
strong bias re: the topic - finding good document editors is a 
persistent problem in many WGs.  At the same time, recognize that if 
you're too far in the rough (which you might be), your own criticisms 
may not result in changes to the doc.
Several folks who were listed as co-authors have offered to assume 
responsibility
for the doc, so the "recruiting" task seems to have been done, at the 
behest of the WG
chairs. As for their bias, I think they have an opportunity to revise 
the document in
a way to avoid a perception of a strong bias, and they should be given a 
chance to do so.


If I am in the rough, perhaps it's because I am one of the very few 
people who
take time to read docs like this, in detail. I recall that Chris 
admitted, at the
mic, that he had not read the adverse actions I-D, so I don't know if he 
also
didn't read (or read carefully) the validation reconsidered doc. I get 
the sense
that folks often express support for a doc based on a slide 
presentation, rather
that reading the doc. Its a problem in many WGs, and this one probably 
is not an exception.


Steve

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Christopher Morrow]

On Fri, Nov 20, 2015 at 11:34 AM, Stephen Kent  wrote:
>
> If I am in the rough, perhaps it's because I am one of the very few people
> who
> take time to read docs like this, in detail. I recall that Chris admitted,
> at the
> mic, that he had not read the adverse actions I-D, so I don't know if he
> also

I didn't read the adverse actions well enough to matter, yes.

> didn't read (or read carefully) the validation reconsidered doc. I get the
> sense

I did read the validation reconsidered doc a few times... most
recently when making the presentation I gave. I didn't enjoy some of
the text as much, and think a bunch of 'clean up the wording' has to
happen, but I do think (as my slides said) that the intent is an
appropriate change to improve robustness of the system.

-chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Randy Bush]

> the intent is an appropriate change to improve robustness of the
> system.

i think it changes the robustness, not necessarily improves it.  the
loss of congruent hierarchic validation is exchanged for accepting some
failures we have yet to see.

being a bit of a naggumite, accepting errors is not big on my agenda.
one of my disagreements with dr postel was the receiver side of the
robustness principle.  this way lies entropic death.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Christopher Morrow]

Pinging this thread to catch anyone who didn't reply but had thoughts
I'd like to close this out tomorrow before 5pm EST (10pm UTC).

thanks!
-chris

On Sat, Nov 21, 2015 at 9:24 AM, Randy Bush  wrote:
>> the intent is an appropriate change to improve robustness of the
>> system.
>
> i think it changes the robustness, not necessarily improves it.  the
> loss of congruent hierarchic validation is exchanged for accepting some
> failures we have yet to see.
>
> being a bit of a naggumite, accepting errors is not big on my agenda.
> one of my disagreements with dr postel was the receiver side of the
> robustness principle.  this way lies entropic death.
>
> randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Montgomery, Douglas]

I would like to see this work continue.  Every public/private working
group that I have been part of that discusses potential incremental roll
out of RPKI based origin validation gets hung up on FUD about the
brittleness of the system.   While validation reconsidered does not solve
all potential threats/errors, it does mitigate one scenario, with
significant potential amplification effects, that I have heard mentioned
in these discussions.

I would prefer to avoid as many failure scenarios as possible, rather that
focus on ways of detecting them when they do occur.

dougm
— 
Doug Montgomery, Mgr Internet & Scalable Systems Research at  NIST/ITL/ANTD





On 11/23/15, 5:13 PM, "sidr on behalf of Christopher Morrow"
 wrote:

>Pinging this thread to catch anyone who didn't reply but had thoughts
>I'd like to close this out tomorrow before 5pm EST (10pm UTC).
>
>thanks!
>-chris
>
>On Sat, Nov 21, 2015 at 9:24 AM, Randy Bush  wrote:
>>> the intent is an appropriate change to improve robustness of the
>>> system.
>>
>> i think it changes the robustness, not necessarily improves it.  the
>> loss of congruent hierarchic validation is exchanged for accepting some
>> failures we have yet to see.
>>
>> being a bit of a naggumite, accepting errors is not big on my agenda.
>> one of my disagreements with dr postel was the receiver side of the
>> robustness principle.  this way lies entropic death.
>>
>> randy
>
>___
>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

Re: [sidr] Validation Reconsidered (again/again) question

[Christopher Morrow]

On Mon, Nov 23, 2015 at 5:13 PM, Christopher Morrow
 wrote:
> Pinging this thread to catch anyone who didn't reply but had thoughts
> I'd like to close this out tomorrow before 5pm EST (10pm UTC).
>

Damn my lack of date specificity!!
  To be clear, I'd like to make the call on this:
2015-11-25 10pm UTC
   (November 25 2015 10pm UTC)

> thanks!
> -chris
>
> On Sat, Nov 21, 2015 at 9:24 AM, Randy Bush  wrote:
>>> the intent is an appropriate change to improve robustness of the
>>> system.
>>
>> i think it changes the robustness, not necessarily improves it.  the
>> loss of congruent hierarchic validation is exchanged for accepting some
>> failures we have yet to see.
>>
>> being a bit of a naggumite, accepting errors is not big on my agenda.
>> one of my disagreements with dr postel was the receiver side of the
>> robustness principle.  this way lies entropic death.
>>
>> randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Wes Hardaker]

Christopher Morrow  writes:

> Pinging this thread to catch anyone who didn't reply but had thoughts
> I'd like to close this out tomorrow before 5pm EST (10pm UTC).

I've been considering the concept behind this document and whether the
concept should be carried forward by the working group.  To me the
starting ID is frequently badly written or has too few editors, etc.
That always changes over time, so I'm not concerned about that issue in
particular until it is proven that no one will take it up (and many
won't volunteer for a question mark).

So, on to the concept: in my younger years I was very strict and I would
have been against this concept from the beginning, because it does bring
the status of a given certificate into question.  But my older and wiser
self has seen far too many difficult and failed protocol deployments
because of the complexity associated with "everyone everywhere needs to
do the right thing all the time".  To me, the validation reconsidered
proposal mitigates some of the very likely real-world, real-human
deployment scenarios.  And I don't think that the RPKI publicity side
can take too many negative hits (again, because I've watched too many
other protocols slow down at the minimum when negative publicity hits
them).  In short, the validation reconsidered concept reduces the
real-world impact of necessary and accidental changes, which to me means
a deployment base that will be stronger even though we're "allowing
more".

Does that do strange things to the status of a given certificate?  Yes,
it definitely does.  I know this will ruffle some feathers: but I
believe the goal of the RPKI was to make a decision, based on available
data, about the ability to trust that origin's announcement.  Everything
else has come after, or more likely as a result of implementing, that goal.
The RPKI makes use of PKIX and certificates to achieve that goal, and
along the way became a fundamental staple that we're hesitant to
change.

In the end, however, when I look at the primary original goal, along
with the need for a robust deployment, the validation reconsidered
proposal seems well worth the trade offs.

-- 
Wes Hardaker
Parsons

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Randy Bush]

> Every public/private working group that I have been part of that
> discusses potential incremental roll out of RPKI based origin
> validation gets hung up on FUD about the brittleness of the system.

universally, the brittleness that seems to concern operators is the
hierarchy and the 'dutch court' attack.  this does nothing for that.

the brittleness this seems to address is perceived by rirs, who have
already deployed.

so i do not see this as solving a real deployment issue.  otoh, i do
not see it as being highly destructive.  more of a not clearly needed
change when there is plenty of other work to be done.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Robert Kisteleki]

On 2015-11-24 23:35, Randy Bush wrote:
>> Every public/private working group that I have been part of that
>> discusses potential incremental roll out of RPKI based origin
>> validation gets hung up on FUD about the brittleness of the system.
> 
> universally, the brittleness that seems to concern operators is the
> hierarchy and the 'dutch court' attack.  this does nothing for that.

Indeed it doesn't solve all possible problems. But it solves a real tangible
one.

> the brittleness this seems to address is perceived by rirs, who have
> already deployed.

RIRs are expected to be higher-than-average in the certificate chain,
therefore any mistake made on this level could affect a large population.
However, the issue addressed can happen on any level and will affect any
descendants -- therefore benefits apply to them to.

> so i do not see this as solving a real deployment issue.  otoh, i do
> not see it as being highly destructive.  more of a not clearly needed
> change when there is plenty of other work to be done.

I don't think we should accept the situation that, for example, my
certificate (and ROA, whatever) covering my precious prefix will become
invalid because my grand-grand-grandparent, whom I never met, made a booboo
about an ASN they never had. Therefore I think this draft, or the concept
therein, should be completed.

Robert

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Warren Kumari]

On Tue, Nov 24, 2015 at 12:58 PM Wes Hardaker  wrote:

> Christopher Morrow  writes:
>
> > Pinging this thread to catch anyone who didn't reply but had thoughts
> > I'd like to close this out tomorrow before 5pm EST (10pm UTC).
>
> I've been considering the concept behind this document and whether the
> concept should be carried forward by the working group.  To me the
> starting ID is frequently badly written or has too few editors, etc.
> That always changes over time, so I'm not concerned about that issue in
> particular until it is proven that no one will take it up (and many
> won't volunteer for a question mark).
>
> So, on to the concept: in my younger years I was very strict and I would
> have been against this concept from the beginning, because it does bring
> the status of a given certificate into question.  But my older and wiser
> self has seen far too many difficult and failed protocol deployments
> because of the complexity associated with "everyone everywhere needs to
> do the right thing all the time".  To me, the validation reconsidered
> proposal mitigates some of the very likely real-world, real-human
> deployment scenarios.  And I don't think that the RPKI publicity side
> can take too many negative hits (again, because I've watched too many
> other protocols slow down at the minimum when negative publicity hits
> them).  In short, the validation reconsidered concept reduces the
> real-world impact of necessary and accidental changes, which to me means
> a deployment base that will be stronger even though we're "allowing
> more".
>
> Does that do strange things to the status of a given certificate?  Yes,
> it definitely does.  I know this will ruffle some feathers: but I
> believe the goal of the RPKI was to make a decision, based on available
> data, about the ability to trust that origin's announcement.  Everything
> else has come after, or more likely as a result of implementing, that goal.
> The RPKI makes use of PKIX and certificates to achieve that goal, and
> along the way became a fundamental staple that we're hesitant to
> change.
>
> In the end, however, when I look at the primary original goal, along
> with the need for a robust deployment, the validation reconsidered
> proposal seems well worth the trade offs.
>

I've been delaying responding because I wasn't sure how to articulate my
thoughts (and because I got sidetracked!).

Wes managed to capture what I was thinking nicely.

We should complete this.

Hopefully I'm not too late for my views to be taken into account.
W


>
> --
> Wes Hardaker
> Parsons
>
> ___
> 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

Re: [sidr] Validation Reconsidered (again/again) question

[Stephen Kent]

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.

Section 2 of the I-D says:

   Validation of signed resource data using a target resource

certificate, and a specific set of number resources, consists of

verifying that the digital signature of the signed resource data is

valid, using the public key of the target resource certificate, and

also validating the resource certificate in the context of the RPKI,
   using the path validation process.



Personally, I have trouble understanding what that 5 1/2 line sentence 
means,

in no small part because the phrase "signed resource data" is not defined
anywhere in the I-D. The text that follows reproduces, with one 
exception, the
path validation description from 6487, so I assume that the text is 
proposing

a change to that path validation process.
PowerPoint Presentation
The one change made to the path validation procedure in RFC 6487 arises
in step 6, which is reworded to be:

The resource extension data contained in this certificate

"encompasses" the entirety of the resources in the specific

resource set ("encompass" in this context is defined in

Section 7.1 of [RFC6487]).

PowerPoint Presentation

PowerPoint Presentation As I noted before, the phrase "_specific_ 
resource set" is undefined in the I-D.
I'm guessing that many folks believe this term refers to any address 
space and ASN
extensions in the cert being validated. That's a simple, reasonable 
interpretation
of the text, and the authors have not stated a different intent, so 
let's proceed
on that assumption. Consider the following example that, WLOG, focuses 
only on

address space.

Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert 
for a ROA.


TA->CA 1->CA 2->ROA


Assume the TA cert contains address space T, U, V, W, X, Y and Z.

Assume the CA 1 cert contains address space T, U, V, and W.

Assume the CA 2 cert contains address space V and W.

Let's say that the ROA EE cert issued by CA 2 contains address space V.

CA 2 is about to receive address space Z from some other ISP, so it has 
asked
CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 
agrees,

and issues a new cert to CA 2 and that cert contains address space V and Z.

Now, under the assumption about what "specific resource set" means, when
an RP tries to validate CA 2's ROA, the "specific resource set" will be 
V, and
so it will be valid, because V is in all of the certs from the TA 
through CA 1

to CA 2. Even though CA 2's cert contains Z, which is not contained
in CA 1's cert, this will not be considered in the validation of the ROA 
EE cert.
This is the desired outcome, because CA 2 has begun the process of 
getting its
new address space (Z), but that process has not broken its CA cert. I 
assume this

is an example of the reduced fragility that is so appealing.

If CA 2 issued a ROA for Z, then validation of that ROA would fail, because
the CA 1  cert does not contain Z. That's good, because the second ROA 
exmaple

ought not be valid, since the transfer has not yet completed.

So far, so good. But, let's look at the implications of this revised 
validation

procedure in greater depth.

What if CA 1, acting on the request from CA 2 asked the TA to add Z to 
CA 2's cert,
in anticipation of the transfer? Then we have a problem, because Z is 
under the
tree from this TA and if it agreed to add Z to CA 1's cert, then a ROA 
for Z,
issued by CA 2, would be valid, even though the transfer had not yet 
been effected.


So, when folks claim that this alg allows for transfers to not have to 
follow
a strict ordering of RPKI actions, that is only partly true. Issuing a 
new CA
cert with resources not yet transferred to the target can actually 
enable the

target to generate bogus ROAs that will validate, unless certain precautions
are taken. Every CA has to be sure that IF it issues a cert to a 
subordinate
because of an anticipated transfer, that this act does not enable the 
subordinate
(or a child of the subordinate ...) to issue bogus ROAs! Right now we 
have no
agreed-upon resource transfer process for the RPKI, to ensure that this 
sort of
vulnerability does not arise. Yet the suggestion is to change the 
validation

procedure before having such a process in place. Not such a good idea.

A bigger problem, IMHO, is that if an RP validates CA 2's (new) cert,
the "specific resource set" will be V and Z (according to the interpretation
cited above). However, using the revised step 6, validation will fail,
because CA 1's cert does not contain Z. To avoid this problem, RPs would 
have
to not validate CA certs that might contain address space that is not 
present

in _all_ the certs along the path.

This is a bad outcome, for two reasons. An RP should 

Re: [sidr] Validation Reconsidered (again/again) question

[Geoff Huston]

Hi,

I’m working through this example and I can’t help but observe that its
"ill-defined and, the most likely interpretation doesn't seem to work”
to borrow your words….

> 
> Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for 
> a ROA.
> 
> TA->CA 1->CA 2->ROA
> 
> 
> Assume the TA cert contains address space T, U, V, W, X, Y and Z.
> 
> Assume the CA 1 cert contains address space T, U, V, and W.
> 
> Assume the CA 2 cert contains address space V and W.
> 
> Let's say that the ROA EE cert issued by CA 2 contains address space V.
> 
> CA 2 is about to receive address space Z from some other ISP, so it has asked 
> CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 
> agrees, 
> and issues a new cert to CA 2 and that cert contains address space V and Z.

CA1 has already issued a cert with subject “CA2” and resources (V,W) - lets 
call this cert No 1

Do you mean: 

a) CA 1 issues a cert  with subject “CA2” and resources (V,Z) - lets call this 
cert No 2

OR the combination of actions:

b)CA 1 issues a SECOND cert  with subject “CA2” and resources (V,Z)  - lets 
call this Cert No 2
   AND
  CA1 revokes the cert with subject “CA2” and resources (V,W) (which we 
call Cert No 1)


> 
> Now, under the assumption about what "specific resource set" means, when
> an RP tries to validate CA 2's ROA,

Now I’m confused - originally the ROA was signed by an EE cert issued by CA 2’s 
Cert No 1

so when you refer to CA 2’s ROA do you mean the ROA that was signed by an EE 
cert issued by CA 2’s Cert No 1,
or do you mean a new ROA signed by an EE issued by CA 2’s Cert No 2?


> the "specific resource set" will be V, and
> so it will be valid, because V is in all of the certs from the TA through CA 1
> to CA 2. Even though CA 2's cert contains Z, which is not contained
> in CA 1's cert, this will not be considered in the validation of the ROA EE 
> cert.
> This is the desired outcome, because CA 2 has begun the process of getting 
> its 
> new address space (Z), but that process has not broken its CA cert. I assume 
> this
> is an example of the reduced fragility that is so appealing. 


So I _think_ you are assuming that there is a new ROA, signed by an EE cert 
issued by 
the CA that has a CA cert issued by CA 1 with resources (V,Z), and evidently 
you are referring
to this new ROA and its new EE cert.


> 
> If CA 2 issued a ROA for Z, then validation of that ROA would fail, because 
> the CA 1  cert does not contain Z. That's good, because the second ROA exmaple
> ought not be valid, since the transfer has not yet completed. 
> 
> So far, so good. But, let's look at the implications of this revised 
> validation 
> procedure in greater depth.
> 
> What if CA 1, acting on the request from CA 2 asked the TA to add Z to CA 2's 
> cert,

Huh?

The TA has issued a cert for subject “CA 1” - Since when did Ca2 have a 
relationship
with the TA?

>  
> in anticipation of the transfer? Then we have a problem, because Z is under 
> the 
> tree from this TA and if it agreed to add Z to CA 1's cert, then a ROA for Z, 
> issued by CA 2, would be valid, even though the transfer had not yet been 
> effected.

I’m having trouble following this - I think you have a typo of otherwise 
confused
the example at this point.

I’ll stop here because I can’t see the point of the ensuring text without some 
additional
clarity and precision of the example scenario that does not invent arbitrary 
relationships
between CAs.

regards,

   Geoff

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Tim Bruijnzeels]

Hi,

> On 25 Nov 2015, at 21:19, Stephen Kent  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

Re: [sidr] Validation Reconsidered (again/again) question

[Declan Ma]

Tim,

Thanks for your explanations.

Yet since the very draft keeps talking about Resource Transfer and deems it as 
one of the  “Operational Considerations” in Section 3, we might pay attention 
to Steve’s statement as below: 


So, when folks claim that this alg allows for transfers to not have to follow 
a strict ordering of RPKI actions, that is only partly true. Issuing a new CA
cert with resources not yet transferred to the target can actually enable the
target to generate bogus ROAs that will validate, unless certain precautions
are taken. Every CA has to be sure that IF it issues a cert to a subordinate 
because of an anticipated transfer, that this act does not enable the 
subordinate
(or a child of the subordinate ...) to issue bogus ROAs! Right now we have no 
agreed-upon resource transfer process for the RPKI, to ensure that this sort of
vulnerability does not arise. Yet the suggestion is to change the validation 
procedure before having such a process in place. Not such a good idea.


As Randy’s draft relating to Resource Transfer is still in progress, it would 
be not wise to seek solutions to the so-called fragility in validating 
certificates when we have no agreed-upon resource transfer process for the 
RPKI. 


Di


> 在 2015年11月26日，20:29，Tim Bruijnzeels  写道：
> 
> Hi,
> 
>> On 25 Nov 2015, at 21:19, Stephen Kent  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

Re: [sidr] Validation Reconsidered (again/again) question

[Geoff Huston]

Declan,

I’d pay more attention to this statement you are quoting if and only if the
justification for this statement made any sense. As far as I can tell the
example used to build to this point is confused and imprecise, so its a
leap of faith that I’m not perform to then hold the conclusions as valid.

I find it equally challenging to then reach the conclusion that you appear to be
providing that that somehow all this is dependant on a draft relating to 
certificate
mediated resource transfer. Again I see what appears to be another leap of 
faith 
going on here.

Geoff



> On 27 Nov 2015, at 12:33 AM, Declan Ma  wrote:
> 
> Tim,
> 
> Thanks for your explanations.
> 
> Yet since the very draft keeps talking about Resource Transfer and deems it 
> as one of the  “Operational Considerations” in Section 3, we might pay 
> attention to Steve’s statement as below: 
> 
> 
> So, when folks claim that this alg allows for transfers to not have to follow 
> a strict ordering of RPKI actions, that is only partly true. Issuing a new CA
> cert with resources not yet transferred to the target can actually enable the
> target to generate bogus ROAs that will validate, unless certain precautions
> are taken. Every CA has to be sure that IF it issues a cert to a subordinate 
> because of an anticipated transfer, that this act does not enable the 
> subordinate
> (or a child of the subordinate ...) to issue bogus ROAs! Right now we have no 
> agreed-upon resource transfer process for the RPKI, to ensure that this sort 
> of
> vulnerability does not arise. Yet the suggestion is to change the validation 
> procedure before having such a process in place. Not such a good idea.
> 
> 
> As Randy’s draft relating to Resource Transfer is still in progress, it would 
> be not wise to seek solutions to the so-called fragility in validating 
> certificates when we have no agreed-upon resource transfer process for the 
> RPKI. 
> 
> 
> Di
> 
> 
>> 在 2015年11月26日，20:29，Tim Bruijnzeels  写道：
>> 
>> Hi,
>> 
>>> On 25 Nov 2015, at 21:19, Stephen Kent  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

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Randy Bush]

> I find it equally challenging to then reach the conclusion that you
> appear to be providing that that somehow all this is dependant on a
> draft relating to certificate mediated resource transfer. Again I see
> what appears to be another leap of faith going on here.

well, not that i makes a lot of difference, but my memory is somewhat
otherwise.  i thought we kind of agreed that we needed to better
understand transfer before we know the constraints and features needed
both in validation reconsidered and the stuff steve is pushing.  but my
memory is not all that i might desire.

randy

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Sriram, Kotikalapudi]

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  on behalf of Tim Bruijnzeels 
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  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

Re: [sidr] Validation Reconsidered (again/again) question

[Sriram, Kotikalapudi]

I think the discussion on the work should continue.
New questions are being raised and the authors should address them in a revised 
draft going forward.

I also had a couple of new questions/suggestions (hopefully new!) about the 
method.
I have mentioned them in my other post replying to Tim's post.

Sriram 

From: sidr  on behalf of Christopher Morrow 

Sent: Thursday, November 5, 2015 8:52 PM
To: sidr@ietf.org; sidr-...@tools.ietf.org; sidr-cha...@ietf.org
Subject: [sidr] Validation Reconsidered (again/again) question

Please take 2 weeks time to consider:

"This document was adopted as a WG work item, should we accept this
change and complete the work or not?"

where:
  'this document' is:
   


I'll close the mic line on: 11/20/2015
Nov 20, 2015

-Chris
sidr-co-chair

___
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

Re: [sidr] Validation Reconsidered (again/again) question

[Geoff Huston]

Hi Sriram,


> On 28 Nov 2015, at 10:52 AM, Sriram, Kotikalapudi 
>  wrote:
> 
> 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.



yes in both cases


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


qualitative judgment: no, not in my view


> 
> 2. How do you perform the validation of a CRL?

RFC6487 provided no guidance, and referred to RFC5280, so that is still the 
case.
nothing changes herre.

> How is it similar to or different from how you validate a ROA?

There are no resources in a CRL so I presume that section 6.1 of RFC5280 is
a good procedure to follow.

> How do you walk the certificate hierarchy in the case of a CRL validation 
> process?
> I.e. How are the "encompassing" rules applied?

huh - I’ll say it again just to be sure: CRLs have no resources.

> I think this should be explicitly explained/clarified in the document.

I disagree.

Geoff


> 
> Sriram  
> 
> 
> From: sidr  on behalf of Tim Bruijnzeels 
> 
> 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  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 CA

Re: [sidr] Validation Reconsidered (again/again) question

[Christopher Morrow]

On Tue, Nov 24, 2015 at 11:22 AM, Christopher Morrow
 wrote:
> On Mon, Nov 23, 2015 at 5:13 PM, Christopher Morrow
>  wrote:
>> Pinging this thread to catch anyone who didn't reply but had thoughts
>> I'd like to close this out tomorrow before 5pm EST (10pm UTC).
>>
>
> Damn my lack of date specificity!!
>   To be clear, I'd like to make the call on this:
> 2015-11-25 10pm UTC
>(November 25 2015 10pm UTC)
>

Ok, with a few extra days to let some more chatter progress, I think
the overall bent here is: "Please do more work on this."

With that in mind, I'd like the authors not gih@ to ping me and i'll
provide a pointer to the current xml, then I hope we can get moving
along with this in the coming quarters.

Thanks to those folk that replied to the question(s).

-chris

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Sriram, Kotikalapudi]

Geoff,

Thanks for your responses. Please see below for my further comments.

>> 2. How do you perform the validation of a CRL?

>RFC6487 provided no guidance, and referred to RFC5280, so that is still the 
>case.
>nothing changes herre.

>> How is it similar to or different from how you validate a ROA?

>There are no resources in a CRL so I presume that section 6.1 of RFC5280 is
>a good procedure to follow.

>> How do you walk the certificate hierarchy in the case of a CRL validation 
>> process?
>> I.e. How are the "encompassing" rules applied?

>huh - I’ll say it again just to be sure: CRLs have no resources.

But what about the CA certificate under which the CRL was issued? 
That certificate has resources in it.
Don't you need to validate that certificate before you validate the CRL?
Does the RP apply the revised (lenient) algorithm in that validation process as 
well?
Or, does the RP need to use two separate validation algorithms -- 
(1) the revised (lenient encompassing) algorithm for ROAs (or EE certs), and
(2) the existing (strict encompassing) algorithm elsewhere?

After re-reading Steve Kent's post, I realize that he asked a similar question 
earlier:
http://www.ietf.org/mail-archive/web/sidr/current/msg07442.html 
(Please see his 3rd last paragraph -- about CRLs)

Sriram 
 
 


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Geoff Huston]

> On 30 Nov 2015, at 8:58 AM, Sriram, Kotikalapudi 
>  wrote:
> 
> Geoff,
> 
> Thanks for your responses. Please see below for my further comments.
> 
>>> 2. How do you perform the validation of a CRL?
> 
>> RFC6487 provided no guidance, and referred to RFC5280, so that is still the 
>> case.
>> nothing changes herre.
> 
>>> How is it similar to or different from how you validate a ROA?
> 
>> There are no resources in a CRL so I presume that section 6.1 of RFC5280 is
>> a good procedure to follow.
> 
>>> How do you walk the certificate hierarchy in the case of a CRL validation 
>>> process?
>>> I.e. How are the "encompassing" rules applied?
> 
>> huh - I’ll say it again just to be sure: CRLs have no resources.
> 
> But what about the CA certificate under which the CRL was issued? 
> That certificate has resources in it.
> Don't you need to validate that certificate before you validate the CRL?
> Does the RP apply the revised (lenient) algorithm in that validation process 
> as well?
> Or, does the RP need to use two separate validation algorithms -- 
> (1) the revised (lenient encompassing) algorithm for ROAs (or EE certs), and
> (2) the existing (strict encompassing) algorithm elsewhere?
> 
> After re-reading Steve Kent's post, I realize that he asked a similar 
> question earlier:
> http://www.ietf.org/mail-archive/web/sidr/current/msg07442.html 
> (Please see his 3rd last paragraph -- about CRLs)


I would’ve thought that if you can establish a chain of Issuer / subject certs 
that
connect a chosen Trust Anchor to the CA that issued the CRL then you have a 
sound reason to
accept the CRL. Given that the CRL has no resources there does not seem to be 
any
resource attribute test that can be applied here.

Geoff

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Andrei Robachevsky]

Tim Bruijnzeels wrote on 26/11/15 13:29:
> 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. 

Tim, I am not sure I understand this. If the parent of the EE cert has a
shrunken set of resources, will it invalidate the EE or only the
non-overlapping subset?

Andrei



signature.asc
Description: OpenPGP digital signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Tim Bruijnzeels]

Hi Andrei

> On 01 Dec 2015, at 12:04, Andrei Robachevsky  
> wrote:
> 
> Tim Bruijnzeels wrote on 26/11/15 13:29:
>> 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. 
> 
> Tim, I am not sure I understand this. If the parent of the EE cert has a
> shrunken set of resources, will it invalidate the EE or only the
> non-overlapping subset?

If the parent has a shrunken resource set this would lead to the EE certificate 
being accepted only for the intersection of its resources, and the parent. 
Because there is a requirement that all prefixes on a ROA are included (and 
accepted in reconsidered) in the resource set of the EE certificate the ROA 
will be considered invalid.

To avoid this it would be better to create one ROA per prefix and avoid fate 
sharing. That way only the ROA(s) for the prefix(es) that are no longer held by 
the (grand)parent(s) are affected.

Tim

> 
> Andrei
> 

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Andrei Robachevsky]

Tim Bruijnzeels wrote on 01/12/15 14:55:
> Hi Andrei
> 
>> On 01 Dec 2015, at 12:04, Andrei Robachevsky  
>> wrote:
>>
>> Tim Bruijnzeels wrote on 26/11/15 13:29:
>>> 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. 
>>
>> Tim, I am not sure I understand this. If the parent of the EE cert has a
>> shrunken set of resources, will it invalidate the EE or only the
>> non-overlapping subset?
> 
> If the parent has a shrunken resource set this would lead to the EE 
> certificate being accepted only for the intersection of its resources, and 
> the parent. Because there is a requirement that all prefixes on a ROA are 
> included (and accepted in reconsidered) in the resource set of the EE 
> certificate the ROA will be considered invalid.
> 

Thank you Tim, this makes sense. Otherwise we will be changing the
semantics of ROA, which is tricky. Could you please point me to the
place where the requirement is specified?

> To avoid this it would be better to create one ROA per prefix and avoid fate 
> sharing. That way only the ROA(s) for the prefix(es) that are no longer held 
> by the (grand)parent(s) are affected.
> 

Right.

Thanks,

Andrei

> Tim
> 
>>
>> Andrei
>>
> 




signature.asc
Description: OpenPGP digital signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Sandra Murphy]

Speaking as regular ol’ member:

On Dec 1, 2015, at 9:42 AM, Andrei Robachevsky  
wrote:

> Tim Bruijnzeels wrote on 01/12/15 14:55:
>>> 
>>> Tim, I am not sure I understand this. If the parent of the EE cert has a
>>> shrunken set of resources, will it invalidate the EE or only the
>>> non-overlapping subset?
>> 
>> If the parent has a shrunken resource set this would lead to the EE 
>> certificate being accepted only for the intersection of its resources, and 
>> the parent. Because there is a requirement that all prefixes on a ROA are 
>> included (and accepted in reconsidered) in the resource set of the EE 
>> certificate the ROA will be considered invalid.
>> 
> 
> Thank you Tim, this makes sense. Otherwise we will be changing the
> semantics of ROA, which is tricky. Could you please point me to the
> place where the requirement is specified?

In RFC6483, page 5, section 4.  ROA Validation:

   o  The IP address delegation extension [RFC3779] is present in the
  end-entity (EE) certificate (contained within the ROA), and each
  IP address prefix(es) in the ROA is contained within the set of IP
  addresses specified by the EE certificate's IP address delegation
  extension.

Quibble.

In the current algorithm, the EE cert that mentioned some of the removed 
resources will be invalid.  That makes the ROA that mentioned some of the 
removed resources be invalid.

Under validation reconsidered, the EE cert will be valid, but not all the 
resources contained in it will be valid.  However, the EE cert still "contains" 
the removed resources, so the ROA “contained within” test would still succeed. 
So a ROA that mentioned some of the removed resources would still be considered 
valid. (I would say that’s bad.)

Under validation-reconsidered, we would need to make sure this section said 
something about the validity of the resources in the valid EE cert.

Just in case it is not obvious:

Suppose the EE cert always contained more resources than the ROA mentioned.

Suppose the ROA did not mention the resources that were removed.  In that case 
the shrinking of the parent causes a shrinking of the set of resources that are 
contained in the EE cert that are considered valid under 
validation-reconsidered.  The valid subset of the resources contained in the 
valid EE cert (i.e., the shrunken resources) would still cover the resources 
mentioned in the ROA.  So a ROA whose resources were contained exclusively 
within the retained resources would be valid.  (I would say that’s good.)

—Sandy, speaking as regular ol’ member

(We’ve overloaded “Valid” a couple of different ways valid certs, valid ROAs, 
valid origins, valid Signature_Blocks, …) - it might be nice to readers and 
users to come up with a different adjective here for the subset of the 
resources that are contained within the certificate, rather than yet another 
use of “valid”.   Before we have to talk about valid certs with invalid 
resources.)



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Declan Ma]

> 在 2015年12月2日，08:32，Sandra Murphy  写道：
> 
> (We’ve overloaded “Valid” a couple of different ways valid certs, valid ROAs, 
> valid origins, valid Signature_Blocks, …) - it might be nice to readers and 
> users to come up with a different adjective here for the subset of the 
> resources that are contained within the certificate, rather than yet another 
> use of “valid”.   Before we have to talk about valid certs with invalid 
> resources.)

Quite reasonable.

According to the discussions on Validation Reconsidered during the past few 
days, I think we need precise terminology. And documenting well-defined 
security problems is yet another critical thing. 

Di
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Geoff Huston]

> On 2 Dec 2015, at 11:32 AM, Sandra Murphy  wrote:
> 
> Speaking as regular ol’ member:
> 
> On Dec 1, 2015, at 9:42 AM, Andrei Robachevsky  
> wrote:
> 
>> Tim Bruijnzeels wrote on 01/12/15 14:55:
 
 Tim, I am not sure I understand this. If the parent of the EE cert has a
 shrunken set of resources, will it invalidate the EE or only the
 non-overlapping subset?
>>> 
>>> If the parent has a shrunken resource set this would lead to the EE 
>>> certificate being accepted only for the intersection of its resources, and 
>>> the parent. Because there is a requirement that all prefixes on a ROA are 
>>> included (and accepted in reconsidered) in the resource set of the EE 
>>> certificate the ROA will be considered invalid.
>>> 
>> 
>> Thank you Tim, this makes sense. Otherwise we will be changing the
>> semantics of ROA, which is tricky. Could you please point me to the
>> place where the requirement is specified?
> 
> In RFC6483, page 5, section 4.  ROA Validation:
> 
>   o  The IP address delegation extension [RFC3779] is present in the
>  end-entity (EE) certificate (contained within the ROA), and each
>  IP address prefix(es) in the ROA is contained within the set of IP
>  addresses specified by the EE certificate's IP address delegation
>  extension.
> 
> Quibble.

RFC6482, section 4

> 
> In the current algorithm, the EE cert that mentioned some of the removed 
> resources will be invalid.  That makes the ROA that mentioned some of the 
> removed resources be invalid.
> 
> Under validation reconsidered, the EE cert will be valid, but not all the 
> resources contained in it will be valid.  However, the EE cert still 
> "contains" the removed resources, so the ROA “contained within” test would 
> still succeed. So a ROA that mentioned some of the removed resources would 
> still be considered valid. (I would say that’s bad.)


I’d say thats bad too.

So how about an example or two:

Example 1:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24

and signs

ROA: 1.0.0.0/24 AS1

all good (assuming that A is a trust anchor)

Example 2:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24, 2.0.0.0/24

and signs

ROA: 1.0.0.0/24 AS1

still all good (assuming that A is a trust anchor)

Example 3:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24, 3.0.0.0/24

and signs

ROA: 1.0.0.0/24 AS1

still all good (assuming that A is a trust anchor)

Example 4:

A CA Cert: 1.0.0.0/24, 2.0.0.0/24

issues:

B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24

issues:

C EE Cert: 1.0.0.0/24, 3.0.0.0/24

and signs

ROA: 1.0.0.0/24, 3.0.0.0/24 AS1

invalid ROA

(or at least that’s my opinion of what should happen. My assumption here is 
that the ROA IS intentionally a collection of resources where the entirety of 
the collection is important, so if all elements of the collection cannot be 
validated via the ROA’s EE certificate then its a dud ROA.)



> 
> Under validation-reconsidered, we would need to make sure this section said 
> something about the validity of the resources in the valid EE cert.


I don’t think its a question of the EE cert, but the question of section 4 of 
RFC6482 and what validation of the ROA means.

> 
> Just in case it is not obvious:
> 
> Suppose the EE cert always contained more resources than the ROA mentioned.


which is ok today under RFC6482

> 
> Suppose the ROA did not mention the resources that were removed.  In that 
> case the shrinking of the parent causes a shrinking of the set of resources 
> that are contained in the EE cert that are considered valid under 
> validation-reconsidered.  The valid subset of the resources contained in the 
> valid EE cert (i.e., the shrunken resources) would still cover the resources 
> mentioned in the ROA.  So a ROA whose resources were contained exclusively 
> within the retained resources would be valid.  (I would say that’s good.)


i.e. thats like my example 3 above, so I agree thats good from where I sit as 
well.

> 
> —Sandy, speaking as regular ol’ member
> 
> (We’ve overloaded “Valid” a couple of different ways valid certs, valid ROAs, 
> valid origins, valid Signature_Blocks, …) - it might be nice to readers and 
> users to come up with a different adjective here for the subset of the 
> resources that are contained within the certificate, rather than yet another 
> use of “valid”.   Before we have to talk about valid certs with invalid 
> resources.)
> 


___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Sandra Murphy]

On Dec 2, 2015, at 5:23 AM, Geoff Huston  wrote:

> 
>> On 2 Dec 2015, at 11:32 AM, Sandra Murphy  wrote:
>> 
>> Speaking as regular ol’ member:
>> 
>> On Dec 1, 2015, at 9:42 AM, Andrei Robachevsky 
>>  wrote:
>> 
>> 
>> In RFC6483, page 5, section 4.  ROA Validation:
>> 
>>  o  The IP address delegation extension [RFC3779] is present in the
>> end-entity (EE) certificate (contained within the ROA), and each
>> IP address prefix(es) in the ROA is contained within the set of IP
>> addresses specified by the EE certificate's IP address delegation
>> extension.
>> 
>> Quibble.
> 
> RFC6482, section 4

Yep, my bad, that’s a typo, the quote is from RFC6482.  Sorry about that.

Attempt to be precise and miss a point.  Hate that.

> 
>> 
>> In the current algorithm, the EE cert that mentioned some of the removed 
>> resources will be invalid.  That makes the ROA that mentioned some of the 
>> removed resources be invalid.
>> 
>> Under validation reconsidered, the EE cert will be valid, but not all the 
>> resources contained in it will be valid.  However, the EE cert still 
>> "contains" the removed resources, so the ROA “contained within” test would 
>> still succeed. So a ROA that mentioned some of the removed resources would 
>> still be considered valid. (I would say that’s bad.)
> 
> 
> I’d say thats bad too.
> 
> So how about an example or two:
> 
<…>

> 
> Example 4:
> 
> A CA Cert: 1.0.0.0/24, 2.0.0.0/24
> 
> issues:
> 
> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24
> 
> issues:
> 
> C EE Cert: 1.0.0.0/24, 3.0.0.0/24
> 
> and signs
> 
> ROA: 1.0.0.0/24, 3.0.0.0/24 AS1
> 
> invalid ROA
> 
> (or at least that’s my opinion of what should happen. My assumption here is 
> that the ROA IS intentionally a collection of resources where the entirety of 
> the collection is important, so if all elements of the collection cannot be 
> validated via the ROA’s EE certificate then its a dud ROA.)

That’s not my understanding of what the text currently says will happen.  Note 
that I am not disagreeing that this is the desired result.  (I did say “that’s 
bad”, above, remember.)

By my understanding of validation-reconsidered, the C EE cert would be valid 
but the valid resources in the valid C EE cert would be only 1.0.0.0/24.

The actual text of RFC6482 says that the “each IP address prefix(es) in the ROA 
is contained within the set of IP addresses specified by the EE certificate's 
IP address delegation extension.”

Set 1: "each IP address prefix(es) in the ROA" :  1.0.0.0/24, 3.0.0.0/24 AS1

Set 2: "the set of IP addresses specified by the EE certificate's IP address 
delegation extension":  1.0.0.0/24, 3.0.0.0/24

is set1 contained within set2?  Yes.

So (under validation-reconsidered) the ROA meets the RFC6482 condition, as the 
text currently stands.  So the ROA would be valid.

> 
>> 
>> Under validation-reconsidered, we would need to make sure this section said 
>> something about the validity of the resources in the valid EE cert.
> 
> 
> I don’t think its a question of the EE cert, but the question of section 4 of 
> RFC6482 and what validation of the ROA means.

Under validation-reconsidered, I would say that the ROA should be valid if the 
IP addresses it contains are contained within the *valid* resources among the 
resources specified in the EE cert.

We need to say that because the valid resources specified in a valid EE cert 
could be a proper subset of the resources specified in the EE cert.  As your 
examples show.  Just “contained within” is not going to be sufficient 
specification.

No biggie, just a need for more precise text, under validation-reconsidered.


>> Suppose the ROA did not mention the resources that were removed.  In that 
>> case the shrinking of the parent causes a shrinking of the set of resources 
>> that are contained in the EE cert that are considered valid under 
>> validation-reconsidered.  The valid subset of the resources contained in the 
>> valid EE cert (i.e., the shrunken resources) would still cover the resources 
>> mentioned in the ROA.  So a ROA whose resources were contained exclusively 
>> within the retained resources would be valid.  (I would say that’s good.)
> 
> 
> i.e. thats like my example 3 above, so I agree thats good from where I sit as 
> well.

Good, then I’ve got that much of validation-reconsidered right.

—Sandy




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Geoff Huston]

> On 3 Dec 2015, at 5:28 AM, Sandra Murphy  wrote:
> 
> 
> On Dec 2, 2015, at 5:23 AM, Geoff Huston  wrote:
> 
>> 
>>> On 2 Dec 2015, at 11:32 AM, Sandra Murphy  wrote:
>>> 
>>> Speaking as regular ol’ member:
>>> 
>>> On Dec 1, 2015, at 9:42 AM, Andrei Robachevsky 
>>>  wrote:
>>> 
>>> 
>>> In RFC6483, page 5, section 4.  ROA Validation:
>>> 
>>> o  The IP address delegation extension [RFC3779] is present in the
>>>end-entity (EE) certificate (contained within the ROA), and each
>>>IP address prefix(es) in the ROA is contained within the set of IP
>>>addresses specified by the EE certificate's IP address delegation
>>>extension.
>>> 
>>> Quibble.
>> 
>> RFC6482, section 4
> 
> Yep, my bad, that’s a typo, the quote is from RFC6482.  Sorry about that.
> 
> Attempt to be precise and miss a point.  Hate that.

I do it all the time. sigh.

> 
>> 
>>> 
>>> In the current algorithm, the EE cert that mentioned some of the removed 
>>> resources will be invalid.  That makes the ROA that mentioned some of the 
>>> removed resources be invalid.
>>> 
>>> Under validation reconsidered, the EE cert will be valid, but not all the 
>>> resources contained in it will be valid.  However, the EE cert still 
>>> "contains" the removed resources, so the ROA “contained within” test would 
>>> still succeed. So a ROA that mentioned some of the removed resources would 
>>> still be considered valid. (I would say that’s bad.)
>> 
>> 
>> I’d say thats bad too.
>> 
>> So how about an example or two:
>> 
> <…>
> 
>> 
>> Example 4:
>> 
>> A CA Cert: 1.0.0.0/24, 2.0.0.0/24
>> 
>> issues:
>> 
>> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24
>> 
>> issues:
>> 
>> C EE Cert: 1.0.0.0/24, 3.0.0.0/24
>> 
>> and signs
>> 
>> ROA: 1.0.0.0/24, 3.0.0.0/24 AS1
>> 
>> invalid ROA
>> 
>> (or at least that’s my opinion of what should happen. My assumption here is 
>> that the ROA IS intentionally a collection of resources where the entirety 
>> of the collection is important, so if all elements of the collection cannot 
>> be validated via the ROA’s EE certificate then its a dud ROA.)
> 
> That’s not my understanding of what the text currently says will happen.  
> Note that I am not disagreeing that this is the desired result.  (I did say 
> “that’s bad”, above, remember.)
> 
> By my understanding of validation-reconsidered, the C EE cert would be valid 
> but the valid resources in the valid C EE cert would be only 1.0.0.0/24.
> 
> The actual text of RFC6482 says that the “each IP address prefix(es) in the 
> ROA is contained within the set of IP addresses specified by the EE 
> certificate's IP address delegation extension.”
> 
> Set 1: "each IP address prefix(es) in the ROA" :  1.0.0.0/24, 3.0.0.0/24 AS1
> 
> Set 2: "the set of IP addresses specified by the EE certificate's IP address 
> delegation extension":  1.0.0.0/24, 3.0.0.0/24
> 
> is set1 contained within set2?  Yes.
> 
> So (under validation-reconsidered) the ROA meets the RFC6482 condition, as 
> the text currently stands.  So the ROA would be valid.


That’s a good point, and in my world that’s not the desired outcome. Which 
implies that a revision of the validation algorithm should have something to 
say about the set of number resources in an EE certificate that can be 
considered  - informally each of the “good” resources in an EE cert must be 
present in each of the CA certs in the validation path. And secondly it should 
specifically consider ROAs, and possibly considere the more generic case and 
consider whether the “bundle” of resources is a critical element of the signed 
attestation. My intuitive reaction is that a ROA is an “all or nothing” 
prospect, so you can’t have a valid ROA with a subset of INRs listed in the 
ROA, but others may see it differently.


> 
>> 
>>> 
>>> Under validation-reconsidered, we would need to make sure this section said 
>>> something about the validity of the resources in the valid EE cert.
>> 
>> 
>> I don’t think its a question of the EE cert, but the question of section 4 
>> of RFC6482 and what validation of the ROA means.
> 
> Under validation-reconsidered, I would say that the ROA should be valid if 
> the IP addresses it contains are contained within the *valid* resources among 
> the resources specified in the EE cert.
> 
> We need to say that because the valid resources specified in a valid EE cert 
> could be a proper subset of the resources specified in the EE cert.  As your 
> examples show.  Just “contained within” is not going to be sufficient 
> specification.
> 
> No biggie, just a need for more precise text, under validation-reconsidered.


agreed by me at any rate.


> 
> 
>>> Suppose the ROA did not mention the resources that were removed.  In that 
>>> case the shrinking of the parent causes a shrinking of the set of resources 
>>> that are contained in the EE cert that are considered valid under 
>>> validation-reconsidered.  The valid subset of the resources contained in 
>>> the valid EE cert (i.e., the

Re: [sidr] Validation Reconsidered (again/again) question

[Declan Ma]

> 在 2015年12月2日，18:23，Geoff Huston  写道：
> 
> 
> 
> Example 2:
> 
> A CA Cert: 1.0.0.0/24, 2.0.0.0/24
> 
> issues:
> 
> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24
> 
> issues:
> 
> C EE Cert: 1.0.0.0/24, 2.0.0.0/24
> 
> and signs
> 
> ROA: 1.0.0.0/24 AS1
> 
> still all good (assuming that A is a trust anchor)
> 
> Example 3:
> 
> A CA Cert: 1.0.0.0/24, 2.0.0.0/24
> 
> issues:
> 
> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24
> 
> issues:
> 
> C EE Cert: 1.0.0.0/24, 3.0.0.0/24
> 
> and signs
> 
> ROA: 1.0.0.0/24 AS1
> 
> still all good (assuming that A is a trust anchor)

Geoff,


In section 2.3 of RFC 6480, the very text says:

For ROAs and manifests, there will be a one-to-one correspondence
   between end-entity certificates and signed objects, i.e., the private
   key corresponding to each end-entity certificate is used to sign
   exactly one object, and each object is signed with only one key.


Due to the so-called one-to-one, why bother to create an EE cert that has more 
INR than its corresponding ROA?

Sorta confused.

Di


> 
> Example 4:
> 
> A CA Cert: 1.0.0.0/24, 2.0.0.0/24
> 
> issues:
> 
> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24
> 
> issues:
> 
> C EE Cert: 1.0.0.0/24, 3.0.0.0/24
> 
> and signs
> 
> ROA: 1.0.0.0/24, 3.0.0.0/24 AS1
> 
> invalid ROA
> 
> (or at least that’s my opinion of what should happen. My assumption here is 
> that the ROA IS intentionally a collection of resources where the entirety of 
> the collection is important, so if all elements of the collection cannot be 
> validated via the ROA’s EE certificate then its a dud ROA.)
> 
> 
> 
>> 
>> Under validation-reconsidered, we would need to make sure this section said 
>> something about the validity of the resources in the valid EE cert.
> 
> 
> I don’t think its a question of the EE cert, but the question of section 4 of 
> RFC6482 and what validation of the ROA means.
> 
>> 
>> Just in case it is not obvious:
>> 
>> Suppose the EE cert always contained more resources than the ROA mentioned.
> 
> 
> which is ok today under RFC6482
> 
>> 
>> Suppose the ROA did not mention the resources that were removed.  In that 
>> case the shrinking of the parent causes a shrinking of the set of resources 
>> that are contained in the EE cert that are considered valid under 
>> validation-reconsidered.  The valid subset of the resources contained in the 
>> valid EE cert (i.e., the shrunken resources) would still cover the resources 
>> mentioned in the ROA.  So a ROA whose resources were contained exclusively 
>> within the retained resources would be valid.  (I would say that’s good.)
> 
> 
> i.e. thats like my example 3 above, so I agree thats good from where I sit as 
> well.
> 
>> 
>> —Sandy, speaking as regular ol’ member
>> 
>> (We’ve overloaded “Valid” a couple of different ways valid certs, valid 
>> ROAs, valid origins, valid Signature_Blocks, …) - it might be nice to 
>> readers and users to come up with a different adjective here for the subset 
>> of the resources that are contained within the certificate, rather than yet 
>> another use of “valid”.   Before we have to talk about valid certs with 
>> invalid resources.)
>> 
> 
> 
> ___
> 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

Re: [sidr] Validation Reconsidered (again/again) question

[Geoff Huston]

> On 3 Dec 2015, at 5:24 PM, Declan Ma  wrote:
> 
> 
> 
> 
> 
>> 在 2015年12月2日，18:23，Geoff Huston  写道：
>> 
>> 
>> 
>> Example 2:
>> 
>> A CA Cert: 1.0.0.0/24, 2.0.0.0/24
>> 
>> issues:
>> 
>> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24
>> 
>> issues:
>> 
>> C EE Cert: 1.0.0.0/24, 2.0.0.0/24
>> 
>> and signs
>> 
>> ROA: 1.0.0.0/24 AS1
>> 
>> still all good (assuming that A is a trust anchor)
>> 
>> Example 3:
>> 
>> A CA Cert: 1.0.0.0/24, 2.0.0.0/24
>> 
>> issues:
>> 
>> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24
>> 
>> issues:
>> 
>> C EE Cert: 1.0.0.0/24, 3.0.0.0/24
>> 
>> and signs
>> 
>> ROA: 1.0.0.0/24 AS1
>> 
>> still all good (assuming that A is a trust anchor)
> 
> Geoff,
> 
> 
> In section 2.3 of RFC 6480, the very text says:
> 
> For ROAs and manifests, there will be a one-to-one correspondence
>   between end-entity certificates and signed objects, i.e., the private
>   key corresponding to each end-entity certificate is used to sign
>   exactly one object, and each object is signed with only one key.
> 
> 
> Due to the so-called one-to-one, why bother to create an EE cert that has 
> more INR than its corresponding ROA?
> 
> Sorta confused.
> 

I have no idea why either - but - the specs don’t say that the resources listed 
in the EE cert must exactly match the
resources in the ROA, so its possible for the EE cert to have a larger number 
resource set than the ROA.


regards,

   Geoff

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Declan Ma]

> 在 2015年12月3日，14:32，Geoff Huston  写道：
> 
> 
>> On 3 Dec 2015, at 5:24 PM, Declan Ma  wrote:
>> 
>> 
>>> 在 2015年12月2日，18:23，Geoff Huston  写道：
>>> 
>>> 
>>> 
>>> Example 2:
>>> 
>>> A CA Cert: 1.0.0.0/24, 2.0.0.0/24
>>> 
>>> issues:
>>> 
>>> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24
>>> 
>>> issues:
>>> 
>>> C EE Cert: 1.0.0.0/24, 2.0.0.0/24
>>> 
>>> and signs
>>> 
>>> ROA: 1.0.0.0/24 AS1
>>> 
>>> still all good (assuming that A is a trust anchor)
>>> 
>>> Example 3:
>>> 
>>> A CA Cert: 1.0.0.0/24, 2.0.0.0/24
>>> 
>>> issues:
>>> 
>>> B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24
>>> 
>>> issues:
>>> 
>>> C EE Cert: 1.0.0.0/24, 3.0.0.0/24
>>> 
>>> and signs
>>> 
>>> ROA: 1.0.0.0/24 AS1
>>> 
>>> still all good (assuming that A is a trust anchor)
>> 
>> Geoff,
>> 
>> 
>> In section 2.3 of RFC 6480, the very text says:
>> 
>> For ROAs and manifests, there will be a one-to-one correspondence
>>  between end-entity certificates and signed objects, i.e., the private
>>  key corresponding to each end-entity certificate is used to sign
>>  exactly one object, and each object is signed with only one key.
>> 
>> 
>> Due to the so-called one-to-one, why bother to create an EE cert that has 
>> more INR than its corresponding ROA?
>> 
>> Sorta confused.
>> 
> 
> I have no idea why either - but - the specs don’t say that the resources 
> listed in the EE cert must exactly match the
> resources in the ROA, so its possible for the EE cert to have a larger number 
> resource set than the ROA.
> 
> 
> regards,
> 
>   Geoff
> 

Indeed.

I am fine with this.

Di,

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Andrei Robachevsky]

Sandra Murphy wrote on 02/12/15 19:28:
> Under validation-reconsidered, I would say that the ROA should be valid if 
> the IP addresses it contains are contained within the *valid* resources among 
> the resources specified in the EE cert.
> 
> We need to say that because the valid resources specified in a valid EE cert 
> could be a proper subset of the resources specified in the EE cert.  As your 
> examples show.  Just “contained within” is not going to be sufficient 
> specification.
> 
> No biggie, just a need for more precise text, under validation-reconsidered.

Agree, the validation reconsidered will require a more precise
definition in RFC6482, something like:

The IP address delegation extension [RFC3779] is present in the
end-entity (EE) certificate (contained within the ROA), and the whole
collection of IP address prefix(es) in the ROA is contained within the
set of IP addresses specified by the EE certificate's IP address
delegation extension that are valid according to the
[validation-reconsidered] checks.

There might be other places that may read ambiguously in light of
validation reconsidered. The thing is that we now have a bunch of
validity concepts: a valid certificate, a valid resource within an
extension of a valid certificate, a valid ROA (and we do not extent this
further to a valid resource within a ROA).

Andrei




signature.asc
Description: OpenPGP digital signature
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Karen Seo]

Just fyi... Steve was out of the country last week and this.  He should 
be back next week...


On 11/25/15 8:11 PM, Geoff Huston wrote:

Hi,

I’m working through this example and I can’t help but observe that its
"ill-defined and, the most likely interpretation doesn't seem to work”
to borrow your words….


Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for a 
ROA.

TA->CA 1->CA 2->ROA


Assume the TA cert contains address space T, U, V, W, X, Y and Z.

Assume the CA 1 cert contains address space T, U, V, and W.

Assume the CA 2 cert contains address space V and W.

Let's say that the ROA EE cert issued by CA 2 contains address space V.

CA 2 is about to receive address space Z from some other ISP, so it has asked
CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 agrees,
and issues a new cert to CA 2 and that cert contains address space V and Z.

CA1 has already issued a cert with subject “CA2” and resources (V,W) - lets 
call this cert No 1

Do you mean:

a) CA 1 issues a cert  with subject “CA2” and resources (V,Z) - lets call this 
cert No 2

OR the combination of actions:

b)CA 1 issues a SECOND cert  with subject “CA2” and resources (V,Z)  - lets 
call this Cert No 2
AND
   CA1 revokes the cert with subject “CA2” and resources (V,W) (which we 
call Cert No 1)



Now, under the assumption about what "specific resource set" means, when
an RP tries to validate CA 2's ROA,

Now I’m confused - originally the ROA was signed by an EE cert issued by CA 2’s 
Cert No 1

so when you refer to CA 2’s ROA do you mean the ROA that was signed by an EE 
cert issued by CA 2’s Cert No 1,
or do you mean a new ROA signed by an EE issued by CA 2’s Cert No 2?



the "specific resource set" will be V, and
so it will be valid, because V is in all of the certs from the TA through CA 1
to CA 2. Even though CA 2's cert contains Z, which is not contained
in CA 1's cert, this will not be considered in the validation of the ROA EE 
cert.
This is the desired outcome, because CA 2 has begun the process of getting its
new address space (Z), but that process has not broken its CA cert. I assume 
this
is an example of the reduced fragility that is so appealing.


So I _think_ you are assuming that there is a new ROA, signed by an EE cert 
issued by
the CA that has a CA cert issued by CA 1 with resources (V,Z), and evidently 
you are referring
to this new ROA and its new EE cert.



If CA 2 issued a ROA for Z, then validation of that ROA would fail, because
the CA 1  cert does not contain Z. That's good, because the second ROA exmaple
ought not be valid, since the transfer has not yet completed.

So far, so good. But, let's look at the implications of this revised validation
procedure in greater depth.

What if CA 1, acting on the request from CA 2 asked the TA to add Z to CA 2's 
cert,

Huh?

The TA has issued a cert for subject “CA 1” - Since when did Ca2 have a 
relationship
with the TA?

  
in anticipation of the transfer? Then we have a problem, because Z is under the

tree from this TA and if it agreed to add Z to CA 1's cert, then a ROA for Z,
issued by CA 2, would be valid, even though the transfer had not yet been 
effected.

I’m having trouble following this - I think you have a typo of otherwise 
confused
the example at this point.

I’ll stop here because I can’t see the point of the ensuring text without some 
additional
clarity and precision of the example scenario that does not invent arbitrary 
relationships
between CAs.

regards,

Geoff

___
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

Re: [sidr] Validation Reconsidered (again/again) question

[Stephen Kent]

Tim,

...
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.
That's a reasonable goal, but it does not match what the revised 
algorithm says.

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

The recommendation you cite belongs in an updated ROA spec.

Essentially that really is all there is to it.
I'm afraid it's not that simple. The statement of what you want to 
accomplish
does not match the algorithm described in Section 5, and that is my 
point, i.e.,

the revised algorithm is not correct.

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.

As I noted above, the algorithm description in Section 5 doesn't match what
you say you want to accomplish. Below is my take on what a revised 
validation
algorithm should say to implement what you and your co-authors seem to 
want to accomplish. You'll note that it is substantially different from 
the text

that appears in the current I-D.

Steve

--

7.2.Resource Certification Path Validation

The following algorithm is employed to validate CA and EE resources 
certificates. It is modeled on the path validation algorithm from 
[RFC5280], but modified to make use of the IP Address Delegation and AS


Identifier Delegation Extensions from [RFC3779].

There are two inputs to the validation algorithm:

1.a trust anchor

2.a certificate to be validated

The algorithm is initialized with the following new variables:

1.If an IP Address Delegation extension is present in the trust anchor 
the address set flag is initialized to TRUE and the address resource 
working set is initialized to the value of this extension. If the 
extension is absent, the flag is initialized to FALSE and the address 
resource working set is initialized to NULL.


2.If an AS Identifier Delegation extension is present in the trust 
anchor, the AS number flag is initialized to TRUE and the AS number 
resource working set is initialized to the value of this extension. If 
the extension is absent, the flag is initialized to FALSE and the AS 
number working set is initialized to NULL.


This path validation algorithm verifies, among other things, that a

prospective certification path (a sequence of n certificates)

satisfies the following conditions:

A.for all 'x' in {1, ..., n-1}, the subject of certificate 'x'

is the issuer of certificate ('x' + 1);

B.certificate '1' is issued by a trust anchor;

C.certificate 'n' is the certificate to be validated; and

D.for all 'x' in {1, ..., n}, certificate 'x' is valid.

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

1.The signature of certificate x is verified using the

public key of the issuer’s certificate (x-1), using the

signature algorithm specified for that public key (in

certificate x-1).

2.The current time lies within the interval defined by the

NotBefore and NotAfter values in the Validity field of

certificate x.

3.The Version, Issuer, and Subject fields of certificate x

satisfy the constraints established in Section 4.1-4.7

of this specification.

4.Certificate x contains all the extensions that MUST be

present, as defined in Section 4.8 of this specification.

The value(s) for each of these extensions MUST be satisfy

the constraints established for each extension in the

respective sections.

5.Any extension not identified in Section 4.8 MUST NOT

appear in certificate x.

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

6.Compute the address space and the AS number working sets
and flags values f

Re: [sidr] Validation Reconsidered (again/again) question

[Tim Bruijnzeels]

Hi Steve,

Without going into every detail.

I understand this is not what the current text says. I provided an alternative 
description to illustrate how I would propose to re-write text. The current 
text takes a bottom-up view of the process w.r.t. verifying the presence of 
resources looking back up the path for a given certificate or object. I believe 
things are much more clear taking a top-down view.

I hope to find time over the next weeks to do this work and would welcome your 
feedback on new text when it is done.

Tim



> On 17 Dec 2015, at 17:27, Stephen Kent  wrote:
> 
> Tim,
>> ...
>> 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.
>> 
> That's a reasonable goal, but it does not match what the revised algorithm 
> says.
>> 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."
> The recommendation you cite belongs in an updated ROA spec. 
>> Essentially that really is all there is to it. 
> I'm afraid it's not that simple. The statement of what you want to accomplish 
> does not match the algorithm described in Section 5, and that is my point, 
> i.e.,
> the revised algorithm is not correct.
>> 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.
>> 
> As I noted above, the algorithm description in Section 5 doesn't match what
> you say you want to accomplish. Below is my take on what a revised validation 
> algorithm should say to implement what you and your co-authors seem to want 
> to accomplish. You'll note that it is substantially  different from the text
> that appears in the current I-D.
> 
> Steve
> 
> --
> 
> 7.2.  Resource Certification Path Validation
>  
> The following algorithm is employed to validate CA and EE resources 
> certificates. It is modeled on the path validation algorithm from [RFC5280], 
> but modified to make use of the IP Address Delegation and AS
> Identifier Delegation Extensions from [RFC3779]. 
>  
> There are two inputs to the validation algorithm:
> 1.  a trust anchor 
> 2.  a certificate to be validated
>  
> The algorithm is initialized with the following new variables:
>  
> 1. If an IP Address Delegation extension is present in the trust anchor the 
> address set flag is initialized to TRUE and the address resource working set 
> is initialized to the value of this extension. If the extension is absent, 
> the flag is initialized to FALSE and the address resource working set is 
> initialized to NULL.
>  
> 2. If an AS Identifier Delegation extension is present in the trust anchor, 
> the AS number flag is initialized to TRUE and the AS number resource working 
> set is initialized to the value of this extension. If the extension is 
> absent, the flag is initialized to FALSE and the AS number working set is 
> initialized to NULL.
>  
>  
> This path validation algorithm verifies, among other things, that a
> prospective certification path (a sequence of n certificates)
> satisfies the following conditions:
>  
>   A.  for all 'x' in {1, ..., n-1}, the subject of certificate 'x'
>   is the issuer of certificate ('x' + 1);
>  
>   B.  certificate '1' is issued by a trust anchor;
>  
>   C.  certificate 'n' is the certificate to be validated; and
>  
>   D.  for all 'x' in {1, ..., n}, certificate 'x' is valid.
>  
>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].
>  
>  
> 1.  The signature of certificate x is verified using the 
> public key of the issuer’s certificate (x-1), using the 
> sig

Re: [sidr] Validation Reconsidered (again/again) question

[Stephen Kent]

Geoff,

Happy new year.



...


Consider a cert path from a trust anchor TA, to CA1 to CA2 to an EE cert for a 
ROA.

TA->CA 1->CA 2->ROA


Assume the TA cert contains address space T, U, V, W, X, Y and Z.

Assume the CA 1 cert contains address space T, U, V, and W.

Assume the CA 2 cert contains address space V and W.

Let's say that the ROA EE cert issued by CA 2 contains address space V.

CA 2 is about to receive address space Z from some other ISP, so it has asked
CA 1 to issue a new CA cert to it, in anticipation of the transfer. CA 1 agrees,
and issues a new cert to CA 2 and that cert contains address space V and Z.

CA1 has already issued a cert with subject “CA2” and resources (V,W) - lets 
call this cert No 1

Do you mean:

a) CA 1 issues a cert  with subject “CA2” and resources (V,Z) - lets call this 
cert No 2

OR the combination of actions:

b)CA 1 issues a SECOND cert  with subject “CA2” and resources (V,Z)  - lets 
call this Cert No 2
AND
   CA1 revokes the cert with subject “CA2” and resources (V,W) (which we 
call Cert No 1)
I intended the second case. Chris pointed out to me in a private message 
that
I failed to include W in this cert; my bad. I intended to have the new 
cert add Z to V and W.

Now, under the assumption about what "specific resource set" means, when
an RP tries to validate CA 2's ROA,

Now I’m confused - originally the ROA was signed by an EE cert issued by CA 2’s 
Cert No 1

so when you refer to CA 2’s ROA do you mean the ROA that was signed by an EE 
cert issued by CA 2’s Cert No 1,
or do you mean a new ROA signed by an EE issued by CA 2’s Cert No 2?
No ROA is "signed" by any cert; a signature on a ROA (or a cert) is 
verified using a cert.


The ROA to which I refer is issued under CA 2 (your Cert 1), and it is 
not new.

I described the ROA when I trued to set the stage for the example:
"Let's say that the ROA EE cert issued by CA 2 contains address 
space V."

the "specific resource set" will be V, and
so it will be valid, because V is in all of the certs from the TA through CA 1
to CA 2. Even though CA 2's cert contains Z, which is not contained
in CA 1's cert, this will not be considered in the validation of the ROA EE 
cert.
This is the desired outcome, because CA 2 has begun the process of getting its
new address space (Z), but that process has not broken its CA cert. I assume 
this
is an example of the reduced fragility that is so appealing.

So I _think_ you are assuming that there is a new ROA, signed by an EE cert 
issued by
the CA that has a CA cert issued by CA 1 with resources (V,Z), and evidently 
you are referring
to this new ROA and its new EE cert.

no, it's the same ROA I defined in the intro to the example.

I'll stop at this point, because the remainder of your comments are
based on the assumption that this was a new ROA, which was not my intent.

Sorry for the typo in the resource set for "Cert 1" and for not being
more explicit in saying that the new Cert for CA 2 was issued by CA 1
as a replacement for the original CA 2 cert.

Steve

___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Re: [sidr] Validation Reconsidered (again/again) question

[Sriram, Kotikalapudi]

Steve,

>but the CA cert used to verify a CRL signature does contain resources,
>and that, I believe, was the issue Sriram was raising, 
>and that my message raised.

To be fair, Geoff did respond to my question:
http://www.ietf.org/mail-archive/web/sidr/current/msg07453.html  
He said:
“I would’ve thought that if you can establish a chain of 
Issuer / subject certs that connect a chosen Trust Anchor
to the CA that issued the CRL then you have a sound reason to
accept the CRL. Given that the CRL has no resources there does not 
seem to be any resource attribute test that can be applied here.”

So, as I understand it now, when validating a ROA or a CRL,
the first basic step (Step #1) is this: 
(Geoff/Tim: This is a description based on my understanding;
please correct me if I got it wrong.)

Step #1: 
Gather the relevant resource CA certs in the cert-path: 
C0, C1, C2, ..., Cn,
where C0 is the TA’s cert and Cn is the final resource holder’s
cert who created the ROA or issued the CRL.
Before saying anything about the ROA or the CRL validity,
first perform a basic check to see if *cert-path is Valid*.
The given *cert-path is Valid* if the following holds:
the signature on cert Ci is Valid when verified 
with the public key associated with cert C(i-1), for all i in 1 <= i <= n. 
In this basic validation process,
no consideration is given to the resources contained in the certs.
So at this step in the algorithm, it is not checked whether 
the resources contained in the certs are “encompassing” or not.
This step only cares about verifying the chain of issuer/subject 
relationships (the successive issuers’ signatures on the certs).
(Proceed to Step #2 if the *cert-path is Valid*.)

Step #2 (in the case of a ROA): 
(Recall that the holder of Cn issued the ROA)
The ROA is Valid if all of the following conditions hold:
(a) The signature on the EE cert is Valid (verified 
with the public key associated with Cn).
(b) The signature on the ROA is valid (verified with
the public key associated with the EE cert).
(c) The prefix resources in the ROA exactly match the 
resources listed in the EE cert.
(d) All the prefix resources in the ROA are contained in the
intersection of the resources listed 
in the set {C0, C1, ..., Cn}.

Step #2 (in the case of a CRL): 
(Recall that the holder of Cn issued the CRL)
The CRL is Valid if all the following conditions hold:
(a) The certificate(s) being revoked in the CRL 
is (are) certificates that were issued earlier 
by the subject (holder) of Cn. 
(b) The signature on the CRL is Valid (verified with 
the public key associated with Cn). 

(Note: No need to look into the list of resources listed in Cn
for CRL validation. Cn can issue a cert C(n+1)
and later revoke it at will by issuing a CRL.
When the CRL is received, for its validation purpose,  we don’t need to 
look at what resources are listed in the revoked cert C(n+1)
and their relation with the resources listed in cert Cn.
Because the resource cert that is being CRL’ed 
is meant to be discarded.) 

Sriram

  



___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr