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.
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. 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 ... >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. 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. 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) >instead forcing everything into a very simplistic "does it verify >to our trust store? Keep the UI uncluttered, if it verifies to the >trust store it's okay for everything". > >Put another way, X.509 itself says that the privilege management >infrustructure will almost always be completely separate from the >certification infrastructure. Why are we using "the simple existence of >a chain which goes up to one of the many authorities we accept" as the >marker for an error-free UI? > >> 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. >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. Paul _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
