On Fri, Jan 27, 2012 at 8:10 PM, Phillip Hallam-Baker <[email protected]> wrote:
I think we should focus on identifying problems at this stage.
I agree.
1) We need to figure out what we're really trying to do. I think it's an attempt to improve the detection rate of impersonation fraud, in an attempt to reduce the likelihood that J Random User will be coerced or seduced into interacting confidentially with someone he thinks is someone else, or has a reputation other than what he perceives. 2) We need to develop a flexible, useful risk model so that we know what our work supports. 3) PKIX and everyone involved has been so interested in getting the singular correct that they've completely lost sight of the possibility of the plural. Every standard is designed to do one thing as best as the designers can, but without any overarching schema or design to pull everything together, and without any thought given to the inevitable demand for redundancy. 4) Every client protocol must patch around PKIX's inability/unwillingness to connect its parts. TLS is a prime example: OCSP Stapling patches the lack of connection between Certificate and the credentials which state that the Certificate really is currently valid. Secure Renegotiation patches the lack of useful, effective, and user-acceptable client authentication. OCSP Stapling would not need to exist if there had been a single portable format to pass around the entire set of authenticators. Secure Renegotiation would not need to exist if the main concerns preventing user (much less admin/developer!) acceptability of client authentication had been addressed. (Information leakage, database matching, and promiscuous advertisement of the identities of the endpoints have been cited, were cited a decade ago even, but nobody fixed them. The idea of a user's computer being the same logical entity as the user himself breaks under the harsh glare of reality: a user's credentials are often used for things of which the user has no knowledge and for which the user never gave consent. I think we need a combination user/application identifier, a kind of overarching user identifier running individual applications under their own userIDs. This would permit finer-grained control than simply the user's login session.) 5) Every client developer believes that the current standards, implementations and designs comprise not only the existing but also the only possible landscape, and innovation is stifled within the standards bodies themselves. This leads to massive fragmentation of the market when different concerns take their cues from existing standards to do the best they can to serve their own needs and semantics as The One True Way. There are no truly flexible, truly extensible solutions which leverage the strength of the ASN.1 parser. 6) We need more than just a single key and proof during handshake. We need multiple authority chains, for multiple authority trusts of multiple types. We need OCSP responses for them, we need timestamps, we need signatures, we need long-term evidence of acceptability at the moment of evaluation. Courts can solve the disputes we can't. We can't fight the existence of disputes. All we can do is our best to be flexible so that we can help our users meet their legal obligations, so that we can reduce the cost of litigation, so that we can reduce the workload on the judiciary. (I speak of this knowing only about US requirements, I will not claim to know anything about other systems.) 7) We need to create stronger means of identifying and authenticating certificates, such that we're not limited solely to the serial number and hash of the DN of the issuer. We need to have a drop-in replacement for the current CRL-fed OCSP responder workflow, preferably such that existing responder implementations won't choke when fed enhanced CRLs with better authentication. (The existence of that workflow is the main reason it doesn't make sense to create something entirely new, and why it does make sense to create CRL extensions to carry strong cert auth information. See draft-hamilton-crl-whitelist-00 for a starting point.) 8) We need to create some means to permit people (including corporate people and individuals) to implement sane and effective key management procedures. For example, why do we have to have high value EV certified keys on the webserver? Why can't we include nameConstraints in leaf certificates, allowing people to certify their own webserver device keys under their declared ownership? (I know it's legacy, X.509 defined it as only being able to occur within CA certificates and RFC5280 inherited that language from its base. Granted, nobody could have foreseen the need, but it's a restriction that reduces the agility of the system. It's a policy-based mandate that has no place in a technical standard.) And most importantly... 9) We must allow our sacred cows to be punctured. No clause in any standard has any divine right of existence, and we need to discard the clauses and semantics in every standard which prevent playing well with others in our world of what are effectively 8+ billion sovereign states. See, X.509 was developed by ITU-T, an arm of UN. The members of UN have committed to minimizing the addition and recognition of new sovereigns, and there are around 250 individual ones on the world stage. In a pool that small, it is just barely feasable for every sovereign to maintain diplomatic relations with every other. (The idea of "the sovereign state" implies absolute power to do whatever it wants in its own internal affairs, without being held to answer by any peer state in any meaningful way.) Now, we personally cannot hold each other to answer. We can petition the state to resolve disputes between us, and the state can hold us to answer in some manner, but we cannot individually personally take matters into our own hands to seize recompense for perceived wrongs against us. We are (legally, at least) immune from direct non-political interference by our peers. In a very real sense, interactions between people (natural and corporate both) are interactions between sovereigns, albeit in a lower order. When the individual goes into business, he is by default a "sole proprietor", and participates in the marketplace as a legal peer to the corporation. The individual has no right to demand that a corporation open its records to him; the corporation equally has no right to demand that any other person open his records to it. Internal affairs are internal affairs, and the only way anything gets dragged into public light is if it's brought to the attention of the state in a way that requires it, or if someone manages to learn about it and make it public. The difference between persons and states is that a state doesn't automatically have laws it can petition for redress under, it can only form treaties and try to jealously guard its own interests from interference by other states. In the lower order of personal sovereignty, the state provides a sort of "default treaty" to its persons, and provides a service to nonviolently resolve disputes under it. (at least in first world countries.) Something that both individuals and states have is "reputation". There is no bar to someone else saying something about you and your interactions over a period of time, as long as it's true. A credit report is a statement of reputation. Your state identity is only an index to the (state-regulated) reputation you've built up. That was all to provide context for this question: if we're going to design something based on a technology designed for sovereigns, can we at least import the correct semantics in the correct place? -Kyle H
Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
