I'd like to discuss some of these before issuing an IETF LC.  There's no 
implied importance based on the order.

0) abstract: I'd delete the 2nd paragraph it really sounds like 
marketing.  The third paragraph is also a repeat of what's in the 1st 
paragraph - I'd just delete it.  Finally, need to be clear that you're 
also defining two new TLS extensions:

  This document specifies a new certificate type and two TLS extensions,
  one for the client and one for the server, 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.

1) s1 does a good job of motivating the need for server side keys but 
falls a little short on client keys.  Why does the intro to the bullet 
list mention how the client can get the server's certificate with the 
last bullet also talking about the client's key?  Also, is the paragraph 
after the bullets just an explicit example of the last bullet?

Seems like the first sentence should be:

   Traditionally, TLS client and server public keys ...

and then maybe:

  Alternative methods are available that allow a TLS clients/servers
  to obtain the TLS servers/client public key:

    o  TLS clients can obtain the TLS server public key from a
       DNSSEC secured resource records using DANE [RFC6698].

    o  The TLS client or server public key is obtained from a
       [PKIX] certificate chain from an Lightweight Directory
       Access Protocol (LDAP) [LDAP] server or web page.

    o  The TLS client and server public key is provisioned into
       the operating system firmware image, and updated via
       software updates. For example:

       * Some smart objects use the UDP-based Constrained
         Application Protocol (CoAP) [I-D.ietf-core-coap] to
         interact with a Web server to upload sensor data at
         a regular intervals, such as temperature readings.
         CoAP [I-D.ietf-core-coap] can utilize DTLS for securing
         the client-to-server communication.  As part of the
         manufacturing process, the embeded device may be
         configured with the address and the public key of
         a dedicated CoAP server, as well as a public key for
         the client itself.

2) s1: The last paragraph needs to indicate that this document defines 
two new certificate extensions:

  This document registers a new value to the IANA certificate
  types registry for the support of raw public keys.  It also
  defines two new TLS extensions, "client_certificate_type" and
  "server_certificate_type".

3) I think the introduction needs to make it very clear that without the 
out-of-band binding between the public key and the entity that no 
authentication is actually being performed.  Add something like the 
following to the end of s1:

   The mechanism defined herein only provides authentication when
   an out-of-band mechanism is also used to bind the public key
   to the entity presenting the key.

4) s3: r/raw public key certificates/raw public keys

5) wrt Figure 3 maybe we can just list the ones we know about? And, RFC 
5480 updated 3279 wrt ECDSA public keys so it needs to point there:

   [RFC3279] and [RFC5480] define the following OIDs:

Key Type             | Document                   | OID
---------------------+----------------------------+-------------------
RSA                  | Section 2.3.1 of RFC 3279  | 1.2.840.113549.1.1
.....................|............................|...................
Digital Signature    |                            |
Algorithm (DSS)      | Section 2.3.2 of RFC 3279  | 1.2.840.10040.4.1
.....................|............................|...................
Elliptic Curve       |                            |
Digital Signature    |                            |
Algorithm (ECDSA)    | Section 2.1.1 of RFC 5480  | 1.2.840.10045.2.1
---------------------+----------------------------+-------------------

                  Figure 3: Example Algorithm Identifiers.

and add 5480 as reference.

Grumble: would have listed RSASSA-PSS but it's not supported.

6) And on those references, I think the references for 3279 and 5480 end 
up normative.  All are standards track so no downref issues.

7) s3: I think it's not just an algorithm it sometimes includes 
additional parameters.  Also need to include the AlgorithmIdentifier 
syntax. I think that means some slight tweaking:

  The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC
  5280 [PKIX] and does not only contain the raw keys, such as the
  public exponent and the modulus of an RSA public key, but also an
  algorithm identifier.  The algorithm identifier can also include
  parameters.  The structure, as shown in Figure 2, is
  encoded in an ASN.1 format and therefore contains length information
  as well.  An example is provided in Appendix A.

    SubjectPublicKeyInfo  ::=  SEQUENCE  {
      algorithm            AlgorithmIdentifier,
      subjectPublicKey     BIT STRING  }

    AlgorithmIdentifier  ::=  SEQUENCE  {
      algorithm               OBJECT IDENTIFIER,
      parameters              ANY DEFINED BY algorithm OPTIONAL  }

               Figure 2: SubjectPublicKeyInfo ASN.1 Structure.

ref:

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, March 2009.

8) I'm thinking we need to say DER encoded in the above as well:

   an DER encoded ASN.1 [X.690] format

here's the reference:

    [X.690]    ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
               Information technology - ASN.1 encoding rules:
               Specification of Basic Encoding Rules (BER), Canonical
               Encoding Rules (CER) and Distinguished Encoding Rules
               (DER).

9) s4.1: Are some words missing from the following:

  In order to indicate the support of out-of-band raw public keys,
  clients MUST include the 'client_certificate_type' and
  'server_certificate_type' extensions extended client hello message.

extensions "in an" extended client hello message?

10) s4.2:  Maybe reword this slightly:

OLD:

  If the client indicated the support of raw public keys in the
  'client_certificate_type' extension in the client hello and the
  server is able to provide such raw public key then the TLS server
  MUST place the SubjectPublicKeyInfo structure into the Certificate
  payload.

NEW:

  If the client hello indicates support of raw public keys in the
  'client_certificate_type' extension and the
  server also supports raw public keys then the TLS server
  MUST place the SubjectPublicKeyInfo structure into the Certificate
  payload.

But, a more important question is the meaning of that paragraph above. 
Doesn't that override the "sorted by client preference" from s3?

11) s6: Got some questions about the following:

   This information will be needed to make
   authorization decisions.  Without a secure binding,
   man-in-the-middle attacks may be the consequence.

1st isn't that authentication.  2nd isn't it masquerade attacks?  3rd 
it's not really a may it's more an is likely to be?

12) In s6, it indicates:

   This document assumes that such
   binding can be made out-of-band and we list a few examples in
   Section 1.

This statement begs the question as to whether there needs to be a 
requirement on protocols that use this extension to specify the method 
used to provide the out-of-band binding.  In other words something like:

   Specifications that make use of the extension MUST specify the
   mechanism by which the identity and the public key are bound.
   Otherwise, authentication is not possible.

13) How are we supposed to check whether key is still considered "good"? 
  If you can't that might be okay, but you need to mention that there's 
no mechanism to support this yet or that that also needs to be done 
out-of-band.

14) Are there any other extensions that don't make sense to negotiate if 
raw keys are chosen?  For example, if the the client and server settle 
on raw keys do either of the ocsp stapling extensions make sense anymore?

15) In s7, ask IANA to point the Certificate's Type Registry to this draft.

spt