[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