Subject: Re: [therightkey] Why the focus on The?

From: "Kyle Hamilton" <[email-masked]>
Date: Sat, 4 Feb 2012 15:27:13 -0800 (Pacific Standard Time)

On Fri, Jan 27, 2012 at 1:26 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> On 01/27/2012 04:02 PM, Kyle Hamilton wrote:
>> Why is everything so single-point-of-failure in the Security working
>> area?  Does it really have to be?
>
> You seem to be suggesting that we should be considering redundant,
> corroborative certification techniques to ensure that the key offered by
> the peer really does belong to the peer.
>
> I agree that any solution which actually improves on the status quo will
> have to include this sort of approach.
>
> I don't think that it follows from this that you'd need to encourage
> people to use multiple keys per entity, though.

I believe it's important to approach the problem from this vantage because we need to ensure that key management and rollover can be easy and hassle-free, the same way that DNS updates can be.

> The best argument i've seen for using multiple keys is the material
> Chris Palmer (i think) wrote about how to deploy public key pinning,
> where having a (presumably offline) backup key per managed entity gives
> you some flexibility if you discover a compromise of pinned key material
> that's currently in use.

Compromise (n): Any reduction in the utility of a public key to the holder of its private key, including but not limited to expiration of a certification, revocation of a certification, private key duplication detection, key disclosure, or loss of private key material.

The reason I put it this way is because it all relates to the holder of the private key, the one who has to do something when he discovers that his certificate is suddenly invalid.  To that person, all eventualities appear the same, and all have the same recovery: rekey, reenroll, reinstall.

> Note that there are some contexts (e.g. sending an e-mail) where the
> peer doesn't have a chance to present you with a key for you to
> evaluate.  in those contexts, your tools will actually need to select a
> single key from the various (hopefully redundant, corroborative)
> discovery mechanisms available to them.  So in those contexts, "the" > is a legitimate article to use.

That is only the case where you're initially looking for a key that the mailbox holder can receive messages addressed to.  After you send a message with one or more of your own keys that you can receive messages addressed to, the initial recipient can reply with some real keys.

Why not a discovery mechanism called "QR code on a card"?  Business cards are easy to forge, so you'd want some form of certification on the reply before you relied on it, but for initial contact it might work.

-Kyle H

---

From: Stephen Kent <[email-masked]>
Date: Mon, 6 Feb 2012 11:25:55 -0500

>>...
>
>Compromise (n): Any reduction in the utility of a public key to the 
>holder of its private key, including but not limited to expiration 
>of a certification, revocation of a certification, private key 
>duplication detection, key disclosure, or loss of private key 
>material.

cert expiration and revocation are not considered compromises in the 
security literature. this is an overly broad definition.

Steve