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":"bob(_at_)example(_dot_)com",
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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp