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

ianG iang at iang.org
Tue Jun 17 17:04:29 EDT 2014


On 17/06/2014 02:02 am, Phillip Hallam-Baker wrote:
> So I am almost at the stage where I can loose PPE (Privacy Protected
> Everything) onto the world. 
> 
> I would like to do a sanity check on the design before starting to get
> actual users since once you do that...


as you're asking for sanity on a crypto list, anything goes ;)


> The ideas are
> 
> 1) Ease of use must be as good or better than no security at all except
> on the rare occasion where a user wants to confirm the level of security
> provided.


Concur most vigorously.

> 2) Format agnostic: I am building on S/MIME right now but the approach
> works with OpenPGP just the same.

CMV.

> 3) Trust model agnostic: Must support direct, trusted third party and
> web of trust models. Plus mixtures of all three.

CMV.

> 4) One size (usually) fits all, no 'high security' or 'advanced user'
> options unless there is a specific reason to believe that only advanced
> users need SHA512 or AES 256 or might lose their key.

CMV.

> Requiring everyone
> to have split keys, a personal CA root etc. whether they think they need
> it or not saves a lot of problems
> 
> So naturally I need to give everyone a personal CA hierarchy as follows:
> 
> 1) Lifelong master root key, The hash of the public portion of this key
> is the user's life long phingerprint. Cert has 100 year expiry, subject
> + issuer name is the phingerprint
> 
> 2) Subroot, is signed by the master root, valid for at least ten years.
> Subject name is the hash of the subroot key
> 
> 
> 3) Static encryption key shared across all user's devices.
> 
> 4) Device signature/authentication key that is unique to a particular
> device.
> 
> 
> So if Alice lives 100 years she might have 2 phingerprint / master roots
> for her whole life (assuming she creates a new one at 18), maybe a dozen
> subroots. 1200 encryption keys and 400 or so device keys.
> 
> Only the master root key has to be escrowed outside the system and this
> can be done through a paper based mechanism as discussed earlier on the
> list and this is entirely under control of the person.
> 
> While (1) signs (2) using X.509 semantics for simplicity, the use of the
> sub-root (2) to sign keys of type 3 or 4 does not need to be through
> PKIX.


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.

You intend to do roll your own for the 3,4.  So I suggest you just start
with 3,4 and migrate upwards with the same formats ...


> This is where I want a JSON type format

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

> so that I can make
> statements such as:
> 
> 'My encryption key for July-2015 if foo, it is preferred that all email
> is encrypted using S/MIME and AES-256. The key may also be used with the
> OpenPGP format.'
> 
> 
> 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?

And, can an attacker do the same?


> I see root keys and endorsements being entered into Certificate
> Transparency like logs.






iang



More information about the cryptography mailing list