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

Attachment: Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey

Reply via email to