[Cryptography] Help please, considering design of personal CA for PPE

Tue Jun 17 21:36:54 EDT 2014

On Tue, Jun 17, 2014 at 7:14 PM, Theodore Ts'o <tytso at mit.edu> wrote:

> On Tue, Jun 17, 2014 at 10:04:29PM +0100, ianG wrote:
> > >
> > > When people endorse each other's keys in this scheme they are going to
> > > be endorsing their lifelong phingerprint corresponding to a masterroot,
> > > not the subroot or use keys.
> >
> > What happens when Alice loses control of her lifelong key?  How does she
> > encourage others to switch to a new one?  Can she sign on to her own new
> > lifelong with the old subroot?
>
> The question of how the lifelong key will be (a) protected so an
> adversary can't obtain the private components, but (b) available so
> Alice and resign the subkeys periodically is to perhaps the trickiest
> part of the design IMO.

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.

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.

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.

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.

>  If the private components are encrypted, then
> the risk is that Alice will forget the password, especially if it is
> but rarely used.

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.

The only way to keep a key really safe is not to have it in a computer at
all.

 And if they aren't encrypted, then they will be
> subject to being disclosed to an authorized party.  Sure, you can
> break it apart using some secret sharing scheme, but how does that
> scale?

Banks have safe deposit boxes.

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.

> And it doesn't solve the problem of how the individual
> components are protected --- they are either encrypted, in which case
> the problems are whether or not the passwords are strong, and whether
> or not the passwords get forgotten, or they aren't encrypted, in which
> case how do you protect them from being stolen?
>

I choose the passwords, they are random with 128 bits of ergodicity.

> Even if they are written on a piece of paper using a QR code, or some
> such, the piece of paper still has to be protected somehow.  Do you
> trust putting it in a safe deposit box?  Does your threat environment
> includes the possibility of a court order demanding access to said
> safe deposit box?
>
> There are solutions, but they all involve tradeoffs.

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.

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.

On Tue, Jun 17, 2014 at 5:04 PM, ianG <iang at iang.org> wrote:

I'm really not sure how the word simplicity can be honestly used in the
> same sentence as X.509.  Nor can I think of any advantage found in using
> X.509 except when dealing with the borg that is legacy code.  And that's
> no advantage, that's a term of service.
>

> My advice, bite the bullet.  Do your own format now.  It will save you
> later.

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.

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.

>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.

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.

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.

Personally, over beers, I'd say forget JSON.  Roll your own binary, you
> will anyway.  But that's really personal preference.

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.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140617/35f62fa2/attachment.html>