Opened 12 years ago

Closed 12 years ago

#4 closed enhancement (wontfix)

Nit Report - ROA Format

Reported by: gih@… Owned by:
Priority: trivial Milestone:
Component: roa-format Version:
Severity: In WG Last Call Keywords:


the only comment I have is that I'd prefer to see a preference order in
validation (section 3) to help relying party S/W writers to make efficient
choices in the validation path - but that isn't a stopping block for me.


Change History (2)

comment:1 Changed 12 years ago 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.

comment:2 Changed 12 years ago by gih@…

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.