Interesting point. The mailing list name came about because everyone thought my suggestion sucked, including me. We don't need to restrict ourselves to one key.
Incidentally, I don't want to get hung up on just doing public key either. We could have easily made XKMS support public and symmetric key from the start. But we didn't think about it and that led to two groups doing what amounted to a re-do. I think we should focus on identifying problems at this stage. On Fri, Jan 27, 2012 at 4:02 PM, Kyle Hamilton <[email protected]> wrote: > All, > > Why are we focusing on 'the' anything? > > Key pinning and CA pinning don't work with only One True Key. The only > usable way to do that kind of thing is to present multiple options. As > certificate chains expire or are discovered to be revoked, those keys would > be removed from the list of acceptable keys. > > We have multiple data paths to the user, and everything that isn't > security-related in IETF is recommended as highly redundant. Why is the > security area different, where everything is so singular and brittle? > > We should be providing multiple TXT records with hashes of multiple > acceptable SPKIs, and cross-referencing them with the SPKIs we receive in > the TLS handshake. We should not, however, rely on this as 'the' way to get > information around. That information should be advisory unless no > certificate chain is presented by the server. (i.e., you can be advised > that you should look for certain keys, and you can also be willing to trust > a certifier. These are not mutually exclusive.) > > We do indeed need certification, and certification does provide a useful > service. It just doesn't do it right now. The problem is the way it's > implemented, preventing it from being useful. Implementors don't want to > spend the time and make the changes to make it more useful, or are too > stubbornly attached to an unworkable model to realize that they need to > change. > > We should also provide more than one certificate chain in our handshakes. > This would permit maintenance of the certificates on the webservers to be > moved to a scheduled maintenance window instead of "OMG our CA is about to > be delisted we have to act NOW". It would also permit different certificate > chains to be presented for different applications without having to define a > new TLS extension. > > Why is everything so single-point-of-failure in the Security working area? > Does it really have to be? > > -Kyle H > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
