We should add Thomas Clause (the shepherd) into this thread as well. (Unfortunately, .all doesn’t reach shepherds if they are not WG chairs, as is the case sometimes.)
Jari On 29 Oct 2014, at 20:47, Martin Thomson <[email protected]> wrote: > On 29 October 2014 03:52, Dearlove, Christopher (UK) > <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
