[TLS] Fwd: AUTH48 [AR]: RFC 7250 <draft-ietf-tls-oob-pubkey-11.txt> changes

["Joseph Salowey (jsalowey)" <[e-mail]>]

There have been some small technical changes to draft-ietf-tls-oob-pubkey-11 during the Auth-48 review process.  The latest diffs with the most significant changes can be found here:

  http://www.rfc-editor.org/authors/rfc7250-lastdiff.html

and the entire diff from draft 11 is here:

  http://www.rfc-editor.org/authors/rfc7250-diff.html

The rational for the changes is included in the message below.  

Please review the changes respond on the list if you have any concern by end of day Friday,  May 30 2014.  

Thanks,

Joe


Begin forwarded message from J. Gilmore
> 
> Here is a second message of my suggested updates to RFC 7250 before
> publication.  Thank you for making the first round of my suggested updates.
> 
> Please change my affiliation:
> OLD:
>  J. Gilmore
> 
> 
> New:
>  J. Gilmore
>  Electronic Frontier Foundation
> 
> My address is OK as it is.
> 
> Section 4.1:
> 
> OLD:
>   The client_certificate_type and server_certificate_type extensions sent in
>   the client hello may carry a list of supported certificate types,
>   sorted by client preference.  It is a list when the client supports
>   multiple certificate types.
> 
> NEW:
>   The client_certificate_type and server_certificate_type extensions sent in
>   the client hello each carry a list of supported certificate types,
>   sorted by client preference.  When the client supports
>   only one certificate type, it is a list containing a single element.
> 
> Notes:  When sent by the client, it is ALWAYS a list.  It may be a list
> containing one value.  When sent by the server, it is always a single
> value (chosen from the client's list).
> 
> OLD:
> 
>   The TLS client MUST omit the client_certificate_type extension in
>   the client hello if it does not possess a raw public key or
>   certificate that it can provide to the server when requested using a
>   certificate_request message or if it is not configured to use one
>   with the given TLS server.  The TLS client MUST omit the
>   server_certificate_type extension in the client hello if it is
>   unable to process raw public keys or other certificate types
>   introduced via this extension.
> 
> NEW:
> 
>   The TLS client MUST omit certificate types from the
>   client_certificate_type extension in the client hello if it does
>   not possess the corresponding raw public key or certificate that it
>   can provide to the server when requested using a
>   certificate_request message, or if it is not configured to use one
>   with the given TLS server.  If the client has no remaining certificate
>   types to send in the client hello, other than the default X.509
>   type, it MUST omit the client_certificate_type extension in the
>   client hello.
> 
>   The TLS client MUST omit certificate types from the
>   server_certificate_type extension in the client hello if it is
>   unable to process the corresponding raw public key or other
>   certificate type.  If the client has no remaining certificate
>   types to send in the client hello, other than the default
>   X.509 certificate type, it MUST omit the entire
>   server_certificate_type extension from the client hello.
> 
> Notes: Three issues in the original text.  It mixes discussion of the
> client_cert extension with the server_cert extension; I broke those
> out into separate paragraphs.  Second, the text did not require
> clients to avoid advertising capabilities that they are not prepared
> to use later.  Third, this extension allows further extension by
> adding types to the IANA registry, but the wording did not accommodate
> that.  When prepared to use *any* of the extended types, including
> the RawPublicKey type that we define, the already existing
> OpenPGP type, and any ones later defined, the TLS client should send
> the client_certificate_type extension.  (Ditto for the
> server_certificate_type extension.)
> 
> 
> Section 4.3:
> 
> OLD:
>   Authentication of the TLS client to the TLS server is supported only
>   through authentication of the received client SubjectPublicKeyInfo
>   via an out-of-band method.
> 
> 
> NEW:
> 
>   When the TLS server has specified RawPublicKey as the
>   client_certificate_type, authentication of the TLS client to the
>   TLS server is supported only through authentication of the received
>   client SubjectPublicKeyInfo via an out-of-band method.
> 
> Notes:  Other forms of authentication are possible, but not when the
> client and server have chosen to use a Raw Public Key certificate.
> 
> Add Section 4.4.  Server Authentication
> 
> NEW:
>   When the TLS server has specified RawPublicKey as the
>   server_certificate_type, authentication of the TLS server to the
>   TLS client is supported only through authentication of the received
>   client SubjectPublicKeyInfo via an out-of-band method.
> 
> Section 5:
> 
> OLD:
>   Figure 6, Figure 7, and Figure 8 illustrate example exchanges.  Note
>   that TLS ciphersuites using a Diffie-Hellman exchange offering
>   forward secrecy can be used with raw public keys, although this
>   document does not show the information exchange at that level with
>   the subsequent message flows.
> 
> NEW:
>   Figure 6, Figure 7, and Figure 8 illustrate example exchanges.  Note
>   that TLS ciphersuites using a Diffie-Hellman exchange offering
>   forward secrecy can be used with a raw public key, although this
>   document does not show the information exchange at that level with
>   the subsequent message flows.
> 
> Notes: Use the singular "a raw public key" since the protocol
> typically only uses one such key.  In general the text has become
> slightly confused between singulars and plurals, which adds to the
> confusion caused by using a plural list of types in the protocol's
> client messages with a singular selection of a type in the otherwise
> identical server messages.
> 
> Section 5.1:
> 
> OLD:
> 5.1.  TLS Server Uses Raw Public Keys
> 
>   This section shows an example where the TLS client indicates its
>   ability to receive and validate raw public keys from the server. 
> 
> NEW:
> 5.1.  TLS Server Uses A Raw Public Key
> 
>   This section shows an example where the TLS client indicates its
>   ability to receive and validate a raw public key from the server. 
> 
> Notes:  Singularize for a single key.
> 
> OLD:
>                          server_certificate_type=(RawPublicKey), // (2)
> 
> NEW:
>                          server_certificate_type=RawPublicKey, // (2)
> 
> Notes:  The server sends back a single certificate type, not a list,
> so it should be shown as a scalar value rather than a single-element list.
> 
> Section 5.2:
> 
> OLD:
>   This section shows an example where the TLS client as well as the TLS
>   server use raw public keys.  This is one of the use cases envisioned
>   for smart object networking.  The TLS client in this case is an
>   embedded device that is configured with a raw public key for use with
>   TLS and is also able to process raw public keys sent by the server.
>   Therefore, it indicates these capabilities in (1).  As in the
>   previously shown example, the server fulfills the client's request,
>   indicates this via the "RawPublicKey" value in the
>   server_certificate_type payload (2), and provides a raw public key in
>   the Certificate payload back to the client (see (3)).  The TLS
>   server, however, demands client authentication, and therefore a
>   certificate_request is added (4).  The certificate_type payload in
>   (5) indicates that the TLS server accepts raw public keys.  The TLS
>   client, who has a raw public key pre-provisioned, returns it in the
>   Certificate payload (6) to the server.
> 
> NEW:
>   This section shows an example where the TLS client as well as the TLS
>   server use raw public keys.  This is one of the use cases envisioned
>   for smart object networking.  The TLS client in this case is an
>   embedded device that is configured with a raw public key for use with
>   TLS and is also able to process a raw public key sent by the server.
>   Therefore, it indicates these capabilities in (1).  As in the
>   previously shown example, the server fulfills the client's request,
>   indicates this via the RawPublicKey value in the
>   server_certificate_type payload (2), and provides a raw public key in
>   the Certificate payload back to the client (see (3)).  The TLS
>   server demands client authentication, and therefore includes a
>   certificate_request (4).  The client_certificate_type payload in
>   (5) indicates that the TLS server accepts a raw public key.  The TLS
>   client, which has a raw public key pre-provisioned, returns it in the
>   Certificate payload (6) to the server.
> 
> Notes:  Use the singular when speaking of a single key.  Remove quotes
> around "RawPublicKey".  Specify which certificate_type payload is being
> used to specify the client's certificate type.  Do not refer to the 
> client as a person ("who"), use which instead.
> 
> OLD:
>                             server_certificate_type=(RawPublicKey)//(2)
>                             certificate, // (3)
>                             client_certificate_type=(RawPublicKey)//(5)
> 
> NEW:
>                             server_certificate_type=RawPublicKey // (2)
>                             certificate, // (3)
>                             client_certificate_type=RawPublicKey // (5)
> 
> Notes:  Show certificate types sent by server as scalars, not lists.
> 
> Section 5.3:
> 
> OLD:
>   This section shows an example combining raw public keys and X.509
>   certificates.  The client uses a raw public key for client
>   authentication, and the server provides an X.509 certificate.  This
>   exchange starts with the client indicating its ability to process
>   X.509 certificates and raw public keys, if provided by the server.
>   Additionally, the client indicates that it has a raw public key for
>   client-side authentication (see (1)).  The server provides the X.509
>   certificate in (3) with the indication present in (2).  For client
>   authentication, the server indicates in (4) that it selected the raw
>   public key format and requests a certificate from the client in (5).
>   The TLS client provides a raw public key in (6) after receiving and
>   processing the TLS server hello message.
> 
> NEW: This section shows an example combining a raw public key and an
>   X.509 certificate.  The client uses a raw public key for client
>   authentication, and the server provides an X.509 certificate.  This
>   exchange starts with the client indicating its ability to process
>   an X.509 certificate, OpenPGP certificate, or a raw public key, if
>   provided by the server.  It prefers a raw public key, since the
>   RawPublicKey value precedes the other values in the
>   server_certificate_type vector.  Additionally, 
>   the client indicates that it has a raw public key for
>   client-side authentication (see (1)).  The server chooses to provide its X.509
>   certificate in (3) and indicates that choice in (2).  For client
>   authentication, the server indicates in (4) that it has selected the raw
>   public key format and requests a certificate from the client in (5).
>   The TLS client provides a raw public key in (6) after receiving and
>   processing the TLS server hello message.
> 
> Notes:  Use the singular where appropriate.  Show how OpenPGP would
> appear in these exchanges.
> 
> OLD:
> server_certificate_type=(X.509, RawPublicKey)
> client_certificate_type=(RawPublicKey) // (1)
>                         ->
>                         <-  server_hello,
>                             server_certificate_type=(X.509)//(2)
>                             certificate, // (3)
>                             client_certificate_type=(RawPublicKey)//(4)
> 
> NEW:
> server_certificate_type=(RawPublicKey, X.509, OpenPGP)
> client_certificate_type=(RawPublicKey) // (1)
>                         ->
>                         <-  server_hello,
>                             server_certificate_type=X.509 // (2)
>                             certificate, // (3)
>                             client_certificate_type=RawPublicKey // (4)
> 
> Notes:  Show that OpenPGP keys can also participate in this protocol.
> Illustrate client preference by the ordering of the vector.  Show
> server selections as scalars rather than as 1-element lists.
> 
> Thank you!
> 
> 	John