ietf-openpgp
[Top] [All Lists]

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

2015-04-11 13:51:14
On Sat, Apr 11, 2015 at 12:14 PM, ianG <iang(_at_)iang(_dot_)org> wrote:
On 1/04/2015 19:56 pm, Phillip Hallam-Baker wrote:

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

I am doing the same.

While I agree that this might look like a lot of unnecessary keys for
people with only one device, it is much simpler to give everyone the
full hierarchy than deal with 'luxury' and 'economy' versions.

Devices break. Devices have a limited life. Thinking poor people have
fewer devices than rich people is probably mistaken.



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?

If someone presents you with a key endorsement for a Barry Obama email
at Harvard.edu that could have been created five minutes ago it is
worthless. If you have the same endorsement and can prove that it was
published twenty years ago when he was a student it is worth a great
deal more.

Enrolling endorsements in notary logs has a dramatic impact on the
trust model. The cost of forging that endorsement goes from zero to
essentially infinity at the time it is created. That is real power.



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" ?

Yes, understanding that is useful. And so is binding to process. An
endorsement created by an iphone app and enrolled is a particular
quantity, etc.


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?

The internet draft I wrote describes some of the benefits in terms of
a timed work factor model.


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.

Trying to work with casual endorsements alone is a mistake. There is
no grounding at any point. The value of endorsements quickly dwindles
to zero through generation loss.

If there are a just a few endorsements that are tied to a specific
process (i.e. a CA process) then the work factor becomes stable and
objective.

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>