<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 17, 2014 at 7:14 PM, Theodore Ts'o <span dir="ltr"><<a href="mailto:tytso@mit.edu" target="_blank">tytso@mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On Tue, Jun 17, 2014 at 10:04:29PM +0100, ianG wrote:<br>
> ><br>
> > When people endorse each other's keys in this scheme they are going to<br>
> > be endorsing their lifelong phingerprint corresponding to a masterroot,<br>
> > not the subroot or use keys.<br>
><br>
> What happens when Alice loses control of her lifelong key? How does she<br>
> encourage others to switch to a new one? Can she sign on to her own new<br>
> lifelong with the old subroot?<br>
<br>
</div>The question of how the lifelong key will be (a) protected so an<br>
adversary can't obtain the private components, but (b) available so<br>
Alice and resign the subkeys periodically is to perhaps the trickiest<br>
part of the design IMO. </blockquote><div><br></div><div>Well first let me backtrack and say 'potentially lifelong'. I think many people would want to rev their master key when they hit 18 for example.</div><div>
<br></div><div>But the point I want to get away from here is the assumption that key management problems can be swept under the carpet by suggesting rolling keys is a trivial issue. </div><div><br></div><div><br></div><div>
To answer Ian, yes, there needs to be provision for someone being able to say that 'this master key is no longer safe to use' and 'this master key is replaced by that one'. But I think that statements of that sort are not part of the PPE base, they are part of the trust systems that can be built on the PPE framework.</div>
<div><br></div><div>The bottom line is that people can change their lifelong keys but doing so except in the simplest 'roll over to this new stronger key' case is going to introduce the risk that relying parties won't accept the change. Which might of course be exactly what you want.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> If the private components are encrypted, then<br>
the risk is that Alice will forget the password, especially if it is<br>
but rarely used. </blockquote><div><br></div><div>It is not yet in the code by where I want to go is that the master key is encrypted [NOT as a P12, I don't trust the code, too damn complex, delivers zero value.] under a strong algorithm and the key is split and the user is given the two halves of the key which can then be printed out on paper.</div>
<div><br></div><div>The only way to keep a key really safe is not to have it in a computer at all.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And if they aren't encrypted, then they will be<br>
subject to being disclosed to an authorized party. Sure, you can<br>
break it apart using some secret sharing scheme, but how does that<br>
scale? </blockquote><div><br></div><div>Banks have safe deposit boxes. </div><div><br></div><div>Most people would probably be more concerned about the mechanism to escrow their decryption key. I an thinking that would use the same scheme but have not come up with the mechanism yet.</div>
<div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">And it doesn't solve the problem of how the individual<br>
components are protected --- they are either encrypted, in which case<br>
the problems are whether or not the passwords are strong, and whether<br>
or not the passwords get forgotten, or they aren't encrypted, in which<br>
case how do you protect them from being stolen?<br></blockquote><div><br></div><div>I choose the passwords, they are random with 128 bits of ergodicity.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Even if they are written on a piece of paper using a QR code, or some<br>
such, the piece of paper still has to be protected somehow. Do you<br>
trust putting it in a safe deposit box? Does your threat environment<br>
includes the possibility of a court order demanding access to said<br>
safe deposit box?<br>
<br>
There are solutions, but they all involve tradeoffs.</blockquote><div><br></div><div>Court orders is another layer. I am not so worried about that though since its lawful intercept which is a very different issue from a Junta of Colonels deciding that they want to read mail of those suspicious hippie types. Lets deal with PRISM and the rest of the illegal stuff first.</div>
<div><br></div><div>Again, this type of issue is something that is best left to the trust model. And the idea of PPE is that you can build any trust model on top of the provided tools.</div><div><br></div><div><br></div><div>
On Tue, Jun 17, 2014 at 5:04 PM, ianG <span dir="ltr"><<a href="mailto:iang@iang.org" target="_blank">iang@iang.org</a>></span> wrote:<br></div><div><br></div><div><br class=""></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"></blockquote>
</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'm really not sure how the word simplicity can be honestly used in the<br>
same sentence as X.509. Nor can I think of any advantage found in using<br>X.509 except when dealing with the borg that is legacy code. And that's<br>no advantage, that's a term of service.<br></blockquote><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">My advice, bite the bullet. Do your own format now. It will save you<br>
later.</blockquote><div><br></div><div>I have no problem with chucking a specification in the bin, standard or no. And ASN.1 is horrible. And I am not even that bothered by 1 million S/MIME and 1 million PGP keys out there: I think most of the people using those would switch if there was an easy to use alternative.</div>
<div><br></div><div>The thing that I can't walk away from is 5 billion email clients that can read encrypted mail sent to them in S/MIME format without the need for additional plugins. I have to be able to read my email on any device if I am going to set the 'please encrypt mail to me' flag but I don't necessarily have to be able to send encrypted mail from my iPhone.</div>
<div><br></div><div><br></div><div>From a pragmatic point of view there are a lot of existing PKI applications that will work without any additional work if the public key is presented in a PKIX certificate. So the key manager has to do PKIX.</div>
<div><br></div><div>And that is why I have spent today working to make C# emit a certificate. Rob tells me the ASN.1 is right but the signatures on the certs won't verify and the private keys won't export despite being marked for export. And Windows Live Mail can't or won't import them.</div>
<div><br></div><div><br></div><div>Now I am perfectly happy providing a second certification path using a sensible format like JSON. Can do that in half an hour with my tools.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Personally, over beers, I'd say forget JSON. Roll your own binary, you<br>will anyway. But that's really personal preference.</blockquote><div><br></div><div>Yep, already did that, I have a scheme JSON-B which is the whole of the JSON tag set but with additional code points to allow blobs of binary data and Unicode strings to be specified as length delimited chunks of data and numeric codes for integers and floating point.</div>
<div><br></div><div><br></div><div> </div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;border-right-width:1px;border-right-color:rgb(204,204,204);border-right-style:solid;padding-left:1ex;padding-right:1ex">
</blockquote></div></div></div>