[hiprg] review of HI revocation draft

["Henderson, Thomas R" <[e-mail]>]

I'd like to start discussion of open issues for the HI revocation draft, the most recent version of which can be found at http://tools.ietf.org/html/draft-irtf-hiprg-revocation-05.  

The stated goal of this informational draft is to analyze the issues surrounding the key revocation issues for the host identity (HI) keys in HIP.  

Section 4.2 provides a taxonomy of permanent key revocation mechanisms.  

Section 5 discusses implicit HI revocation, by virtue of associating valid lifetimes directly in the HOST_ID parameter, or by specifying the lifetime by a trusted authority (certificate).  The section discusses the issues of how to implement a lifetime bound on the HI and directions for updating resolution systems to provide this information.

Section 6 discusses explicit HI revocation via mechanisms such as CRLs, and the issues that make such explicit revocation difficult operationally.  There is some discussion about extending RVS to serve as some kind of a trusted authority to map old (revoked) HIs to new HIs.

Section 7 discusses issues such as HI refreshment for current HIP associations, suggesting that Update packets can be used to signal the transition.  It also discusses issues surrounding how to communicate HI revocation securely if the HI has been compromised.

This document does not mandate new specification, but it does suggest that some extensions to HIP (support for online HI refreshment via UPDATEs, support for HI lifetimes) could be made.  It does predict that various HI revocation approaches will be adopted to support multiple use cases.

In my opinion, one of the purposes of a document like this is to guide future readers to the issues, considerations, and background literature surrounding a topic.  I tend to think that it is helpful to organize drafts like this around use cases, and try to cover those use cases well while explicitly excluding those use cases or items that are out of scope for the draft.  I believe that this draft could be improved if it were made more clear up front what use cases were covered and what were out of scope, and that some additional text on scoping and organization would help before submitting for review.  However, I realize this is a subjective assessment and would appreciate other opinions on this.

I would like to ask the research group to please review and comment on the document's readiness for publication and for an endorsement as a product of the RG, and if not, are there specific things that could be improved upon to reach that state?  

- Tom

p.s I had some comments about a year ago on this draft that were posted here:  http://www.ietf.org/mail-archive/web/hiprg/current/msg00816.html;  many have since been addressed.