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
