On 30 September 2015 at 09:01, Eran Messeri <[email protected]> wrote: > improvements - just like Tom Ritter created a Chromium patch to require CT > (which he unfortunately didn't submit for proper review), others can present
I had a discussion with the people in charge of that area of Chrome about a similar topic, and re-notified them when I made my blog post. They had previously indicated they were eschewing additional complexity for now and didn't reply about suggesting integrating the require-CT idea. If there is a chance at actually landing the code, I will go back and clean it up, but if it's going to sit out for 4 releases and then need to be mostly-redone I'll wait a bit longer. Let's take this offline with the appropriate people. Going back to Bryan's idea, I'd like to understand a little bit more about the crypto and its constraints. I apologize for not thoroughly reading the paper but I hope you'll humor me ... So it's an N-of-M scheme producing a single signature. I gather than M needs to be decided upon in the beginning, on set-up, and all the shares need to be created by a single entity and then provided to the independent entities? Is this understanding correct? That's unfortunate, as it still represents a single point of trust. It's less, to be sure, and I don't think it's insurmountable for the 'normal' person's notion of trust, but I'm less sure about the legal "This organization is going to have some sort of agreement with some other organizations and lawyers have read it" notion of trust. If you expect to give a key share to, say, ICANN and to CNNIC you need to be able to say you're pretty darn independent. Is there any way to let people generate their own key shares and then assemble them into a public key? Fixing M in the beginning seems to be an engineering problem more than a trust one. You're committing yourself to this many shares, and as time goes on and organizations stop signing, M will stay the same but the potential number of signers will decrease, and trust will gradually erode as well. If I understand that the key shares are part of a Merkle Tree, it seems it might be possible to grow M and add key shares? This would change the public key of course, but I'm assume we can handle the rotation. Also, the slides mention "1-of-k" but I assume it's truly N-of-M and not 1-of-M correct? Because we should assume at least 1 if not a few orgs will have their key share compromised and we need to set N high enough that the average security of the group of organizations is high enough that compromising N orgs would be difficult. I think I communicated this before, but I'm supportive of the idea, I'm just skeptical about the practicality of it. Not from a math or engineering aspect, but from a humans-interfacing-with-humans aspect. But if there's code that runs, clear instructions to follow, and a test network to join - I have a spare box I would set to participating =) -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
