Hi Julien, my take on this is that we need to produce a standards-track document specifying exactly that. This is what our charter says about it:
https://datatracker.ietf.org/wg/hip/charter/ > o Specify in a standards track RFC how to carry certificates in the > base exchange. This was removed from the base HIP spec so that the > mechanism is specified in a stand-alone spec. Cheers, Gonzalo On 21/09/2012 2:49 AM, Julien Laganier wrote: > On Fri, Jul 27, 2012 at 9:22 AM, Ari Keranen <[email protected]> > wrote: >> Hi Julien, >> >> >> On 7/6/12 3:37 AM, Julien Laganier wrote: >>> >>> - 5203bis (registration) can IMHO be republished as is as I haven't >>> seen any issue with the original version. If people agree I could >>> republish it and we could WGLC it... >> >> >> I posted some comments about 5203bis earlier this year but back then there >> was no discussion regarding them. So, here goes again. >> >> Some of these have been discussed also earlier on this list (these relate to >> requirements discovered with the native NAT traversal draft [1]), but I'll >> have them all here for easier reference. >> >> Currently, the registrar has no way of indicating that it would otherwise >> accept the registration, but it's currently running low on resources. For >> this purpose, a failure type "Insufficient resources" could be added to the >> "registration failure types". >> >> Registration using authentication with certificates could be part of the >> registration RFC. Currently, only authentication with HI is defined, but >> knowing all HIs beforehand is not practical in many cases. >> >> Text in section 3.2. of [1] could be used as a basis for this (just replace >> "HIP' data relay" with "registrar"). Also, if this authentication mode is >> added to the draft, failure type "Invalid certificate" should be added for >> the failure case. >> >> Should we have these in the registration draft? >> >> [1] http://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal > > I was going to shamelessly copy/paste section 3.2 of [1] in the > registration draft but I noticed that [1] actually has a normative > dependency on RFC 6253 "Host Identity Protocol Certificates" which is > Experimental. Thus adding the support for certificates to a standard > track HIP registration would cause a so-called downref which could be > problematic... > > Gonzalo - what is your take on this? > > --julien > _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
