Re: [openpgp] public logging of e-mail certificates [was: Re: OpenPGP private certification]

[ianG <[e-mail]>]

On 1/04/2015 19:56 pm, Phillip Hallam-Baker wrote:
> OK, this is what I am planning to do for PrismProof email.
>
> After trying a number of approaches I have concluded that the best
> approach today is to insist that each keypair have exactly one
> purpose.


Concur.

> So Alice will always have a personal root key and an intermediate key
> signing key and the fingerprint of this PKI is the hash of the keyinfo
> block of the personal root. to do key endorsement she will also need a
> key endorsement key on each device she wants to use for endorsements.
>
> Alice-Personal-Root -> Key Signing Key -> Key Endorsement Key[s]


OK.  (at least, it mirrors what I do.)

> [One reason for the no sharing rule for KEKs is that it makes dealing
> with a stolen phone etc. much easier]

By that you mean, one KEK per device, not the common proxy SSL device 
rule of one cert shared across all.  OK, agreed if so.

However I'm not sure you'll hit the mark on the stolen phone.  Much of 
the world only has a phone, so it also has to deal with the full 
hierarchy.  A more comprehensive solution is needed.  In my work, I 
duplicate the phone's (encrypted) db onto server (cloud) and then try to 
recover that and get her up and going when Alice loses her phone.  But I 
freely admit it is flawed as it is weakening the entire security to the 
level of her password/pin, in some shared or non-shared form, and 
relying on a bunch of assumptions that for anyone but a security geek 
look exceedingly mushy.


> Each cert in this chain would be enrolled in an append-only
> cryptographic log which provides proof that it existed at a particular
> point in time. But none of these certs requires an email address.
>
> For various reasons, we probably want these certs to be enrolled in a
> transparent log that publishes both the block chain and the input
> data. It is not necessary for a log to publish the input values to fix
> them in time however.


You're saying that the KEKs are published in their entirety, but they do 
not include any sensitive information.  Just a signing hash that points 
back up to the cert hierarchy.

So what is your motive for timestamping / proof of existence here - to 
stop people creating sybils?


> When Alice endorses Bob, this is not an operation currently supported
> by PKIX and so the 'no new ASN.1' rule applies. The endorsement is
> probably some sort of JSON structure:
>
> {"name":"Bob",
>   "email":"[e-mail]",
>    fingerprint":"phb:qweflkqwhjdflkjhasdlkjhasdvlkjhlksajvh",
>    "date":"2015-04-01:01:23Z",
>    "blind":"askfasjkldhkjashdvkjhsadkjh"}
> <...Signature data...>
>
> This is of course simply another form of certificate but it is a very
> different type of cert so its best to use a different term.


Yes.  But it in itself is also quite defined.  So, in the above, Alice 
endorses Bob lacks any sense of "for what?"  Do we need a different 
endorsement for each "what" or are we looking for a general endorsement 
and a "what policy" or a "what statement" ?

> Alice is
> not going to commit to managing the endorsement lifecycle.

Agreed.  But she is going to be pissed when it breaks on her.


> The property we want to get from enrolling the endorsement in a log is
> to fix it in time. So we enroll the hash in the log rather than the
> endorsement itself.


So, a log can be used for:  fixing in time, publishing, proof of 
existence without time, proof of revocation, ... possibly other things. 
  Do you have a sense that we know enough about the endorsement to be 
able to tie down those benefits?

Reason I ask is this:  in my work, the endorsements are shared amongst a 
group, but not further.  They are replaceable.  And they are analisable. 
  So they aren't really private but they aren't published.  (They are 
also wrapped up in a legal context.)

My question then comes down to finding the low layer endorsement brick 
that allows me to build my castle of trust.

> The value "blind" is a random value that leaks Alice's RNG to the
> NSA^h^h^h^h^h^h^h^h prevents dictionary attacks.


:)


iang