> On 30 Oct 2014, at 09:24, Jari Arkko <jari.ar...@piuha.net> wrote: > > We should add Thomas Clause (the shepherd) into this thread as well. >
Fabulous, thank you Jari. I will read up on this, try to understand the proxy-DISCUSS raised by Adrian. > (Unfortunately, .all doesn’t reach shepherds if they are not WG chairs, as is > the case sometimes.) That does sound like something, which would be an easy fix in the tools set-up, and which probably would be a good fix (assuming that Shepherds are supposed to be of use to the process). Thomas > Jari > >> On 29 Oct 2014, at 20:47, Martin Thomson <martin.thom...@gmail.com> wrote: >> >> On 29 October 2014 03:52, Dearlove, Christopher (UK) >> <chris.dearl...@baesystems.com> wrote: >>> Any objection that something better can be done needs to provide that >>> something better, not just say "asymmetric, therefore something better". >> >> That's a totally fair comment. I was trying for expediency, since >> that is fairly obvious to me. Here's a rough sketch: >> >> A has the same properties you describe: a secret that only it knows >> (KSAK) and a paired public value (KPAK) that it can distribute. >> >> X generates a secret (analogous to SSK) and passes a signature over >> some material (optionally its identity, as you note above, plus the >> paired public value) to A. A provides X with a signature over the >> both the public value and identity that X can subsequently use to >> claim that identity to others with the KPAK (analogous to PVT). X is >> expected to keep that value secret also. >> >> Then X can send message in the form (data || PVT || sig(SSK, data || >> PVT)), and Y can validate both sig and PVT to establish that this is >> valid. >> >> I'm not saying that this is strictly better. It is more complex; RFC >> 6507 seems to cleverly roll the identity of X into the public key it >> uses to sign. But this has the property that private keys aren't >> shared. That means that you can implement this using an HSM that >> enforces a strict containment for keys. It also means that you can >> establish a parallel bases for trust to the single authority. >> >> >> I think that this highlights the reason we call out downrefs in the >> process. As a standalone information RFC, the abstract presentation >> of RFC 6507 is perfectly innocuous. But it's application to a >> standards track effort does open questions about suitability. >> >> You claim that this is an improvement over the status quo, and that is >> quite clear. The scheme prevents participants from impersonating each >> other, which might not have been possible with a system based on a >> shared symmetric key. It does however, require that all trust is >> placed in an authority. I believe that we can do better. >> >> Maybe the property I'm describing here not valuable in the deployment >> context this is designed for and maybe this can be addressed by >> establishing firm expectations about applicability. Maybe a simple >> applicability statement would suffice. That is above my pay grade to >> decide. I'll defer to the IESG on this one. >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
