Re: [therightkey] Basically, it's about keeping the CAs honest

["Kyle Hamilton" <[e-mail]>]

On Tue, Feb 14, 2012 at 7:04 PM, Paul Lambert <[e-mail]> wrote:
>
> I notice you're still attaching a root certificate of unknown quality as part of your signature.  Since it is different than my current class 2 root for the same named authority it may or may not be valid.  If I accept your certificate and root I'm potentially at risk that you will later maliciously create MITM certs.  I could work harder to validate the certificate constraints or attributes ... but even as a supposed expert, trying to figure out the lineage and veractiy of a new certificate is a pain.

Pedantically, as I mentioned, it's not a root.  S/MIME specifies that every CA in the chain except the root be included.

I must ruefully note: the fact your software doesn't handle "standard" X.509 semantics says that the implementors of our standards aren't getting it right, either.  What's wrong here?

> My point here is not to berate your signature, but to try and refocus some discuss away from your pronounced requirement of allowing "approved MITMs" and find at least one thing in your thread that I agree with.

I used to be a crypto pure idealist, believing that it could solve all disputes.  Then the real world (literally!) shot me in the back.

Now, I'm a crypto pragmatic idealist.  The world has evolved the way it has simply because it has.  We have to fit into this world, and it would help a lot if we didn't try to supplant the courts.

Don't let the ideal become the enemy of the acceptance of management of all uses of our standards.

> Ah ... here it is ...
>
>>The flaw is in the trust model implemented by the browsers which (taking
>>its cue from this insistence on a binary "Correct" or "Crap")
>
> No ... binary can be ok ... here it really is ...

It can be okay, in very simple environments.  Implementation is never that simple.  Every decision is an analog process informed at best by multiple binary inputs and at worst with corrupted-but-apparently-legitimate inputs.  (If you're crossing the street, you look both directions to obtain the binary "is a car coming from the direction I'm looking" twice, and decide based on both answers and whether there's a pedestrian island in the middle whether to go.)

My goal: Get every message on the Internet encrypted by December 2017.  I know it's unattainable, but it's what I'm shooting for.

>>categorically cannot acknowledge different authorities for different
>>tasks,
>
> Ok. This is interesting topic.  If I accept a random certificate it should
> be able to be constrained by the user/admin to a specific range of usage.
> For TLS and classic PKI, this would be a range of DNS names.

I agree: I, as my own policy-creating principal, should be permitted to be able to whimsically disregard any statement which I don't believe is legitimate.  (This happens in such cases as the Chinese Government CA.)

See, DNS names are held by an Authority (ICANN, created and explicitly chartered by US federal law).  Individual names are held by the public registry of birth and death (another Authority), and corporate names are held by the Secretaries of State of the various jurisdictions (also an Authority).  Each of these is useful in a different context and for a different purpose.  Trademarks and patents and copyrights are also held and registered by Authority, and are as much property as a phone or vehicle or self-label is.  Why can't I have a certificate chain on the implementations I purchase licenses to which state that a given patent is officially licensed?  Oh, that's right, because not every authoritative registration is important enough to be certifiable.

The CAs we're trusting are trusted to only supply information about the keyholder which the keyholder can legitimately claim to own via a register maintained by Authority.  (While you don't necessarily own your own name, you can decide what you're named.)

Names are labels for people.  Public keys are labels for their private keys, which are known or available only to their holders.  Private key holders are people (or hardware employed by people).  So, I'm going to go out on a limb and suggest that "public keys can be considered to be labels for people", which reduces to "public keys can be considered to be names".

One has the right to choose what identities he puts forth in any environment, and he owns the reputation he's built up over time under those identities.  This is why things like identity theft (impersonation fraud) are bad, they rob people of the time they invested.  However, he does not have the right for others not to ask about him.  Any identity's reputation can be checked instantly once that identity is known, subject only to limits placed by law on financial, health, and false disclosures.  (libel and slander laws)

Also, there are legitimate reasons for one person to have many identities.  They're like "doing business as" (or d/b/a) labels, the same way that corporations have many brand identities and lines of business.  The thing is, these exist independent of any CA's recognition.  Any time we try to place a limit against behavior that legitimately occurs in the wild, we're engaging in an activity which is reserved for legislators alone.

Why doesn't the software in the world today provide this capacity?  Oh, that's right, it's because it's an all-or-nothing atomic structure, you either accept all of it /and every semantic that the absolute implicit trust implies/ or you accept none of it.

> Right now, all the root certs in my store can create certificates in
> most any range.  A fundamental principle we need to consider is local
> end-point constraint of trust.

The fundamental principle we need to consider, from which derives your principle, is "the owner of the machine is for all practical purposes a minor deity in a world of natural and corporate minor deities."  A natural person and a corporate body are both bodies, and a natural person has as much need for and right to control over his own world as a corporation has for its.  Both of these types of minor deities can be held accountable by the greater deities (the things we call 'states').

I can't hold you accountable.  I can ask the state to hold you accountable, but I cannot directly violate any right of yours.  If I do, you can ask the state to hold me accountable.  Even if I'm hired by the state and have some measure of authority to my work, I also cannot simply barge in and violate your rights.  For our purposes, you are a soveregn, a law-making authority over your own affairs, and I have no jurisdiction there.  IETF has no jurisdiction there.  You can violate rfc2804 all you like, and I can't hold you accountable.  I can violate it all I like, and you can't hold me accountable.  Third parties can (and do!) violate it, and we can't hold them accountable.

The only thing we can do is create a new class of certificates: from entities untrusted to provide authoritative identity information but otherwise trustworthy for some local policy.  (And to prevent this happening in the future, we should create guidance for what to do when a chain from an unknown certifier is encountered.)

> If I could do this - then the random root cert that I accept for
> your signature could be locally constrained to be just for you or
> a small domain range (e.g. an enterprise)

I wholeheartedly agree.  Why doesn't software allow for it?  Oh, right, because everything is binary in the software and there's no way to patch all of the binary decisions together because every decision is one decision.

>>> Keeping rfc2804 in mind, when fixing the weaknesses in the trust model
>>> of TLS, maintaining wiretapping capabilities is *NOT* appropriate.
>
> Yes!  Excellent rfc2804 statement/position and a good foundation
> to not design in MITMs.

The problem is, IETF cannot afford the psychosis of unacknowledged reality.  It will happen no matter what we do, write, or say.  There do exist (contrary to popular belief) good reasons for it happening.  People will always demand the capacity, no matter what we think should be right or legitimate or legal, because our attempt to mandate it is not legal or legitimate or right.

>>I think it's incredibly naive to adhere to the directions and demands of
>>a document created on the cusp of a technology which suddenly had a much
>>broader potential than had ever been considered before.  We've got the
>>Law of Deployment Inertia against us: if we try to create something
>>which breaks compatibility with existing systems, nobody will upgrade.
>
> Huh?  MITMs are bad as a design requirement.  They are easy to create
> if you want - go ahead, but not as a core architectural principle.

Perhaps I'm taking too much from the "harm reduction" lobby, but... if we don't plan for them, they're simply going to do another end run around the end-to-end guarantees we try to make in this effort.  We will have as little control over the process at that time as we do now.  Outlawing them will only continue the arms race.

Perhaps I can draw an analogy: If you hired someone to figure out how to reduce the damage in accidents done on your city streets, and that someone came back with a recommendation "ban automobiles on the streets", you wouldn't be happy.  If he came back with "everyone must drive a 1912 Ford Model T", you wouldn't be happy.  Perhaps one might be happy if he came back with "everyone must drive a 1950s-era muscle car," but that would be counterproductive.  That's pretty much what the Internet has done with us, and what we've to this point given them.

If we allow for it with clear user-interface gudelines, we make it less desirable for the actual owners to spend the time recompiling their software to make their own roots appear green or blue.  (In fact, right now, they always appear blue the same way that DV/OV certificates do, which is the prime reason it does violate the end-to-end guarantee.)  If we allow for them, we diminish the returns available to the owners in doing such.  All we need is for us to implement our software so that it won't throw a hissy fit if it's presented with something from one of these sub-trustworthy authorities, and all that relies on is clear guidance (in the same manner as the CA/Browser Forum's EV green bar guidance) for what to do when something our narrow minds can't conceive is correct.

Really, who is the IETF to tell any user or implementor what he can or can't do?  The sheer conceit is appalling.

-Kyle H