On Fri, Nov 14, 2014 at 7:42 PM, Dr. Massimiliano Pala <massimiliano.p...@gmail.com> wrote: > (a) Defining new transport protocols for revocation information availability > (e.g., OCSP over DNS or OCSP over LDAP)
OCSP lacks for various bindings to various transports. I think defining more such bindings would be nice. > (b) (Possibly) defining a more lightweight revocation mechanisms (e.g. > Lightweight Revocation Tokens) What would that look like? I think stapled DANE is about as light-weight as it's going to get. > (c) (Possibly) helping other working groups to revise and update how > revocation information are provided (e.g., the client authentication case) They can do this themselves. Assuming TLS 1.3 retains user authentication with certificates, let the TLS WG add stapled OCSP. > (d) (Possibly) introducing privacy consideration when it comes to revocation > checking If you staple OCSP then the main privacy considerations are: a) how the end entities' certs and OCSP responses are transported (e.g., we'd need TLS to have a mode that provides confidentiality to the client cert, which IIUC is not in the cards for 1.3), b) how to provide privacy protection for DNS (the elephant in the room). Anything to be done in TLS belongs squarely in the TLS WG. I'd love to see DNS confidentiality, but I think we should get our priorities straight: opportunistic security, TLS 1.3, CT, DNSSEC/DANE deployment, ... I confess that my list of priorities is something one could argue about, and that if we have the energy to do more of these things concurrently, then we should. Nico -- _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
