Subject: Re: [sidr] #4: Nit Report - ROA Format

From: "sidr issue tracker" <[email-masked]>
Date: Sun, 29 Nov 2009 20:50:59 -0000

#4: Nit Report - ROA Format
-----------------------------+----------------------------------------------
 Reporter:  gih@…            |       Owner:     
     Type:  enhancement      |      Status:  new
 Priority:  trivial          |   Milestone:     
Component:  roa-format       |     Version:     
 Severity:  In WG Last Call  |    Keywords:     
-----------------------------+----------------------------------------------

Comment(by gih@…):

 Matt Lepinski has said on the mailing list: My interpretation of your
 comment is that you would like to see a prescribed (or recommended) order
 for the checks performed in ROA validation. I am reluctant to put in such
 a prescribed ordering in this document for two reasons: (1) It doesn't
 affect ROA semantics or the interoperation of relying party software with
 ROA producing software; (2) I don't think there is an obviously correct
 order (in particular, there exist multiple relying party implementations
 today and I do not believe that they all perform the checks in the same
 order).

 With regards to number (2) above, to minimize the time to process a set of
 ROAs one must consider both the probability that a check succeeds (in
 general, checks that are likely to fail should be performed sooner) and
 the cost of performing a given check at a given point in the processing
 (in general, inexpensive checks should be performed before expensive
 ones). The former probability depends on the population of invalid ROAs
 (e.g., what will be the greatest source of invalid ROAs in the system? ...
 perhaps expired/revoked end-entity certificates?) The latter cost is
 highly implementation dependent (e.g., the cost to validate the end-entity
 certificate will greatly depend on the data structures that are used to
 store and process certificates).

 In any case, if the working group feels that there is a clear recommended
 processing order that we can provide in Section 3 that will increase the
 likelihood the implementors produce efficient software, then please send
 some text and I'd be happy to insert it.

-- 
Ticket URL: <http://zinfandel.levkowetz.com/wg/sidr/trac/ticket/4#comment:1>
sidr <http://tools.ietf.org/sidr/>

---

From: "sidr issue tracker" <[email-masked]>
Date: Sun, 29 Nov 2009 20:53:06 -0000

#4: Nit Report - ROA Format
-----------------------------+----------------------------------------------
 Reporter:  gih@…            |        Owner:         
     Type:  enhancement      |       Status:  closed 
 Priority:  trivial          |    Milestone:         
Component:  roa-format       |      Version:         
 Severity:  In WG Last Call  |   Resolution:  wontfix
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by gih@…):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 Terry has responded - In hindsight I think that any recommendations of
 ordering should exist in
 some other document (akin to the one you alluded to in the thread on
 sidr-arch-09 refresh cycle) which covers more operational aspects.

-- 
Ticket URL: <http://zinfandel.levkowetz.com/wg/sidr/trac/ticket/4#comment:2>
sidr <http://tools.ietf.org/sidr/>