So, what's blocking the progress on this is the lack of STD track CERT
draft.
Samu and Tobi, would you have cycles to move your experimental track
CERT RFC into STD track draft? I guess not much (or anything except the
category?) need to be changed from the current RFC doc.
Cheers,
Ari
On 9/21/12 11:11 AM, Gonzalo Camarillo wrote:
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
