It would be good to get your feedback here as well as this document relates to the the holder-of-the-key concept (with the exchange of the raw public key in TLS).
Ciao Hannes Begin forwarded message: > From: Hannes Tschofenig <[email protected]> > Date: July 11, 2012 1:56:40 PM GMT+03:00 > To: [email protected] > Cc: Hannes Tschofenig <[email protected]> > Subject: draft-ietf-tls-oob-pubkey: The Open Issue > > Hi all, > > draft-ietf-tls-oob-pubkey specifies a new TLS certificate type for exchanging > raw public keys in Transport Layer Security (TLS) and Datagram Transport > Layer Security (DTLS) for use with out-of-band public key validation. > > Here is the latest draft: > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03 > > I would be great to get your feedback on an open issue that concerns the > semantic of the exchange. I believe there are three use cases we would like > to support with this work. Below, I provide high level message exchanges to > explain those: > > I) Server uses Raw Public Keys (client authentication happens at some other > layer) > (the DANE use case) > > client_hello, > raw-public-key-indicator="Server, when you send me your raw public key? I > support this out-of-band key validation using DANE." -> > > <- server_hello, > raw-public-key="OK. The certificate structure > below contains my raw public key.", > certificate, // with raw public key inside > server_key_exchange, > server_hello_done > > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Client and Server use Raw Public Keys > (the smart object use case - CORE working group) > > client_hello, > raw-public-key="Server, please send me your raw public key and I will then > send you mine. Are you OK processing my raw public key for client > authentication?" -> > > <- server_hello, > raw-public-key="Below you find my raw public key > and please send me your raw public key for client > authentication", > certificate, // raw public key > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Hybrid Scenario > (the OAuth Holder-of-the-Key Use case) > > client_hello, > raw-public-key="I would like to use my raw public key for client > authentication with OAuth. I also process X.509 for server-side > authentication." -> > > <- server_hello, > raw-public-key="Please send me your raw public > key. I use X.509 for server-side authentication", > certificate, // with X.509 cert. > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > -------- > > QUESTION: Are these all the message exchanges we need? Are there some > problems with the exchanges? > > Ciao > Hannes > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
