Hi Erk, Hi Robert, Hi Nikos, thanks for your quick response. Here is an attempt to summarize your input.
-------- I use three types of indications in the message exchange below for improved clarity, namely: (a) 'cert-receive=(value-1, value-2, ..., value-n)' with the meaning: "I accept certificate of the following types (value-1, ..., value-n) if you send them to me." The list is ordered by preference. (b) 'cert-send=(value-1, value-2, ..., value-n)' with the meaning: "I could send you certificate of the following types (value-1, ..., value-n) if you ask." The list is ordered by preference. (c) cert-info=(value) with the meaning: "The certificate payload in this message contains a certificate of the following type". I) Server uses Raw Public Keys (client authentication happens at some other layer) (the DANE use case) client_hello, cert-receive=(Raw, X.509) // (1) cert-send=() -> // (2) <- server_hello, cert-info=(Raw),// (3) certificate, // (4) server_key_exchange, server_hello_done client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) Client accepts to receive two types of certificates, preferring raw public keys. (2) The client does not have a raw public key nor an X.509 certificate for client authentication. (3) The server decides to sends his raw public key and indicates this in the cert-info field. (4) The certificate payload contains the raw public key. II) Client and Server use Raw Public Keys (the smart object use case - CORE working group) client_hello, cert-receive=(Raw) // (1) cert-send=(Raw) -> // (2) <- server_hello, cert-info=(Raw),// (3) certificate, // (4) certificate_request, // (5) cert-receive=(Raw) // (6) server_key_exchange, server_hello_done cert-info=(Raw), // (7) certificate, // (8) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) Client accepts to receive raw public keys. (2) The client does have a raw public key for client authentication. (3) The server decides to sends his raw public key and indicates this in the cert-info field. (4) The certificate payload contains the raw public key. (5) The server wants to use client authentication and and sends a cert-request. (6) The certificate request asks for a certificate of type 'raw' (knowing that the client supports it from (2)). (7) The client indicates that the certificate payload contains a raw public key (8) Here is the payload of the certificate itself. III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) client_hello, cert-receive=(X.509, Raw) // (1) cert-send=(Raw) -> // (2) <- server_hello, cert-info=(X.509),// (3) certificate, // (4) certificate_request, // (5) cert-receive=(Raw) // (6) server_key_exchange, server_hello_done cert-info=(Raw), // (7) certificate, // (8) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) Client accepts to receive X.509 certs and raw public keys, in this order of preference. (Could also be X.509 only in this example) (2) The client does have a raw public key for client authentication. (3) The server decides to sends his X.509 cert and indicates this in the cert-info field. (4) The certificate payload contains the X.509 cert. (5) The server wants to use client authentication and sends a cert-request. (6) The certificate request asks for a certificate of type 'raw' (knowing that the client supports it from (2)). (7) The client indicates that the certificate payload contains a raw public key. (8) Here is the payload of the certificate itself. -------- Do these indications clarify the semantic? I personally believe so. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth